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FOREWORD 

This  material  is  published  as  part  of  Contract  N00014- 
76-C-0732  with  the  Office  of  Naval  Research,  United  States 
Department  of  the  Navy,  entitled.  The  International  Purdue 
Workshop  on  Industrial  Computer  Systems  and  Its  Work  in 
Promoting  Computer  Control  Guidelines  and  Standards . This 
contract  provides  for  an  indexing  and  editing  of  the  results 
of  the  Workshop  Meetings,  particularly  the  Minutes,  to  make 
their  contents  more  readily  available  to  potential  users. 

We  are  grateful  to  the  United  States  Navy  for  their  great 
help  to  this  Workshop  in  this  regard. 


Theodore  J.  Williams 
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BACKGROUND  INFORMATION  ON  THE  WORKSHOP 


The  International  Purdue  Workshop  on  Industrial  Computer 
Systems,  in  its  present  format,  came  about  as  the  result  of  a 
merger  in  1973  of  the  Instrument  Society  of  America  (ISA) 
Computer  Control  Workshop  with  the  former  Purdue  Workshop  on 
the  Standardization  of  Industrial  Computer  Languages,  also 
cosponsored  by  the  ISA.  This  merger  brought  together  the 
former  workshops ' separate  emphases  on  hardware  and  software 
into  a stronger  emphasis  on  engineering  methods  for  computer 
projects.  Applications  interest  remains  in  the  use  of  digital 
computers  to  aid  in  the  operation  of  industrial  processes  of 
all  types. 

The  ISA  Computer  Control  Workshop  had  itself  been  a 
renaming  in  1.967  of  the  former  Users  Workshop  on  Direct  Digi- 
tal Computer  Control,  established  in  1963  under  Instrument 
Society  of  America  sponsorship.  This  Workshop  in  its  annual 
meetings  had  been  responsible  for  much  of  the  early  coordina- 
tion work  in  the  field  of  direct  digital  control  and  its 
application  to  industrial  process  control.  The  Purdue  Work- 
shop on  Standardization  of  Industrial  Computer  Languages  had 
been  established  in  1969  on  a semiannual  meeting  basis  to 
satisfy  a widespread  desire  and  need  expressed  at  that  time 
for  development  of  standards  for  languages  in  the  industrial 
computer  control  area. 


The  new  combined  international  workshop  provides  a 
forum  for  the  exchange  of  experiences  and  for  the  development 
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of  guidelines  and  proposed  standards  throughout  the  world. 

Regional  meetings  are  held  each  spring  in  Europe,  North 
America  and  Japan,  with  a combined  international  meeting 
each  fall  at  Purdue  University.  The  regional  groups  are 
divided  into  several  technical  committees  to  assemble  imple- 
mentation guidelines  and  standards  proposals  on  specialized 
hardware  and  software  topics  of  common  interest.  Attendees 
represent  many  industries,  both  users  and  vendors  of  indus- 
trial computer  systems  and  components,  universities  and 
research  institutions,  with  a wide  range  of  experience  in 
the  industrial  application  of  digital  systems.  Each  workshop 
meeting  features  tutorial  presentations  on  systems  engineer- 
ing topics  by  recognized  leaders  in  the  field.  Results  of 
the  workshop  are  published  in  the  Minutes  of  each  meeting, 
in  technical  papers  and  trade  magazine  articles  by  workshop 
participants,  or  as  more  formal  books  and  proposed  standards. 
Formal  standardization  is  accomplished  through  recognized 
standards-issuing  organizations  such  as  the  ISA,  trade  assoc- 
iations, and  national  standards  bodies. 

The  International  Purdue  Workshop  on  Industrial  Computer 
Systems  is  jointly  sponsored  by  the  Automatic  Control  Systems 
Division,  the  Chemical  and  Petroleum  Industries  Division,  and 
the  Data  Handling  and  Computations  Division  of  the  Instrument 
Society  of  America,  and  by  the  International  Federation  for 
Information  Processing  as  Working  Group  5.4  of  Technical 
Committee  TC-5. 
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The  Workshop  is  affiliated  with  the  Institute  of  Electri- 
cal and  Electronic  Engineering  through  the  Data  Acquisition  and 
Control  Committee  of  the  Computer  Society  and  the  Industrial 
Control  Committee  of  the  Industrial  Applications  Society,  as 
well  as  the  International  Federation  of  Automatic  Control 
through  its  Computer  Committee. 
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INTRODUCTION 

The  Office  of  Naval  Research  of  the  Department  of  the 
Navy  has  made  possible  an  extensive  report,  summary  and  in- 
dexing of  the  work  of  the  International  Purdue  Workshop  on 
Industrial  Computer  Systems  as  carried  out  over  the  past 
eight  years.  The  work  has  involved  twenty-five  separate  work- 
shop meetings  plus  a very  large  number  (over  100)  of  separate 
meetings  of  the  committees  of  the  workshop  and  of  its  regional 
branches.  This  work  has  produced  a mass  of  documentation 
which  has  been  severely  edited  for  the  original  minutes  them- 
selves and  then  again  for  these  summary  collections. 

A listing  of  all  of  the  documentation  developed  as  a 
result  of  the  U.  S.  Navy  sponsored  project  is  given  in  Table  I 
at  the  end  of  this  Introduction.  The  workshop  participants 
are  hopeful  that  it  will  be  helpful  to  others  as  well  as 
themselves  in  the  very  important  work  of  developing  guidelines 
and  standards  for  the  field  of  industrial  computer  systems  in 
their  many  applications. 

This  part  reports  the  work  of  two  major  committees  of 
the  Workshop,  the  Industrial  Real-Time  FORTRAN  Committee  and 
the  Problem-Oriented  Languages  Committee. 

The  Industrial  Real-Time  FORTRAN  Committee  has  been 
working  closely  with  the  Standards  and  Practice  Board  of  the 
Instrument  Society  of  America  (ISA) , and  through  them  to  the 
American  National  Standards  Institute  (ANSI) , and  the  Inter- 
national Standards  Organization  (ISO) , to  develop  a set  ol 
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standards  for  extensions  to  the  FORTRAN  language  to  make  it 
a capable  and  worthwhile  industrial  process  control  and  data 
handling  language.  To  facilitate  that  work  ISA  has  consti- 
tuted the  American  Regional  Branch  of  the  Industrial  Real- 
Time  FORTRAN  Committee  as  Committee  SP61,  Industrial  FORTRAN, 
to  develop  standards  in  this  area.  Three  such  standards  are 
issed  or  contemplated  as  follows: 

561 . 1 - Industrial  Computer  System  FORTRAN 

Procedures  for  Executive  Functions , 

Process  Input/Output , and  Bit  Manipu- 
lation. Originally  published 
September  1972,  Revised  and  Republished 
September  1976,  Instrument  Society  of 
America . 

561 . 2 - Industrial  Computer  System  FORTRAN 

Procedures  for  File  Access  and  the 
Control  of  File  Contention.  Presently 
under  Review.  To  be  Published  by  the 
Instrument  Society  of  America. 

561 . 3 - Industrial  Computer  System  FORTRAN 

Procedures  for  Management  of  Parallel 
Activities . Under  Development. 

The  S61.1  and  S61.2  documents  are  reprinted  here.  The 
latest  committee  working  papers  on  tasking  or  parallel 
activities  management  in  FORTRAN  are  also  included.  Because 
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TABLE  I 


A LIST  OF  ALL  DOCUMENTS  PRODUCED  IN  THIS 
SUMMARY  OF  THE  WORK  OF  THE 
INTERNATIONAL  PURDUE  WORKSHOP  ON  INDUSTRIAL 
COMPUTER  SYSTEMS 


1 . The  International  Purdue  Workshop  on  Industrial  Computer 
System  and  Its  Work  "in  Promo tine  Computer  Control  Guide- 
lines and  Standards , Report  Number  77 , Purdue  Laboratory 
for  Applied  Industrial  Control,  Purdue  University,  West 
Lafayette,  Indiana,  Originally  Published  May  1976,  Re- 
vised November  1976. 


An  Index  to  the  Minutes  of  the  International  Purdue 
Workshop  on  Industrial  Computer  Systems  and  Its  Pro- 
cessor Workshops , Report  Number  88 , Purdue  Labor a very 
for  Applied  Industrial  Control,  Purdue  University.  West 
Lafayette,  Indiana,  January  1977. 


A Language  Comparison  Developed  by  the  Long  Term  Pro- 
cedural Languages  Committee  - Europe , Commi ttee  TC-T 
of  Purdue  Europe , Originally  Published  January  197  6 , 
Republished  October  1976. 


Significant  Accomplishments  and  Documentation  of  the 
International  Purdue  Workshop  on  Industrual  Computer 
Systems . 

Part  I_  - Extended  FORTRAN  for  Industrial  Real- 

Time  Appl icatious  and  Studies  in  Probl cm 
Oriented  Languages. 


Part  II  - The  Long  Term  Procedural  Language . 


Part  III-  Developments  in  Interfaces  and  Data  Trans- 
mission , in~ Man-Machine  Communication:  and 

In  the  Safety  and  Security  of~Industrial 
Computer  Systems . 


Part 


IV  - Some  Reports  on  the  State  of  the  Art  and 
Function  ill-  Requirements  for  Future 


rations . 
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TABLE  I (Cont.) 


Documents  on  Existing  and  Presently  Proposed 
Languages  Related  to  the  Studies  or  the 
Workshop . 


Guidelines  for  the  Design  of  Man/Machine 
Interfaces  for  Process  Control 


All  dated  January  1977. 

The  latter  seven  documents  are  also  published  by  the 
Purdue  Laboratory  for  Applied  Industrial  Control,  Purdue 
University,  West  Lafayette,  Indiana. 
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of  the  existence  of  the  final  or  near  final  documents  the 
development  papers  on  the  first  two  standards  are  not  in- 
cluded here. 

An  excellent  file  handling  system  for  industrial  com- 
puter systems  developed  by  Royal  Dutch  Shell  in  the  Nether- 
lands is  reproduced  here  from  the  1970  Fall  Workshop. 

The  Problem-Oriented  Language  Committee  has  its  choice 
of  two  possible  modes  of  operation  in  this  area.  The  first 
is  to  propose  the  development  and  standardization  of  one  or 
more  problem-oriented  languages  in  any  one  or  more  of  the 
several  possible  formats  in  which  such  languages  can  appear. 
The  second  is  to  develop  a mechanism  by  which  any  such 
language,  in  whatever  format,  can  be  translated  into  one  of 
the  major  high  level  procedural  languages  now  undergoing  the 
standardization  process,  such  as  FORTRAN  or  the  LTPL. 

Because  of  the  extremely  difficult  task  of  carrying  out 
the  first  proposal  above  due  to  the  very  large  number  of  the 
languages  which  already  exist,  it  has  been  decided  to  pursue 
the  second  avenue.  The  key  to  such  work  is  the  use  of  a 
string  processing  language  such  as  STAGE  2,  described  herein, 
to  translate  the  subject  language,  whatever  its  form,  into 
FORTRAN  or  the  LTPL  once  this  latter  has  been  developed.  The 
second  part  of  this  volume  contains  several  committee  docu- 
ments and  reports  concerning  these  possibilities. 
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SECTION  I 


ISA  Standard  S61.1 


INDUSTRIAL  COMPUTER  SYSTEM  FORTRAN  PROCEDURES 
FOR  EXECUTIVE  FUNCTIONS,  PROCESS  INPUT/OUTPUT, 
AND  BIT  MANIPULATION 


Developed  by  the  Industrial  Real-Time  FORTRAN  Committee 
of  the  Workshop  through  ISA  Standards  Committee  SP61.  Ori- 
ginally published  by  ISA  September  1972.  Revised  and 
reissued  September  1976. 
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PREFACE 

This  Preface,  all  footnotes  and  all  Appendices  are  included  for  informational  purposes  and  are  not  part  of  Standard 
ISA-S61.1. 

This  Standard  lias  been  prepared  as  a part  of  the  service  of  the  Instrument  Society  of  America  toward  a goal  of  uniformity  in 
the  field  of  instrumentation.  To  be  of  real  value  this  document  should  not  be  static  but  should  be  subjected  to  periodic 
review.  Toward  this  end  the  Society  welcomes  all  comments  and  criticisms  and  asks  that  they  be  addressed  to  the  Standards 
and  Practices  Board  Secretary,  Instrument  Society  of  America,  100  Stanwix  Street,  Pittsburgh,  Pennsylvania  15222. 

The  ISA  Standards  Committee  on  Industrial  Computer  System  FORTRAN  Procedures  SP61,  operates  within  the  ISA 
Standards  and  Practices  Department,  W.  B.  Miller,  Vice  President.  The  SP61  Committee  also  is  a working  group  of  the 
FORTRAN  Committee  of  the  international  Purdue  Workshop  on  Industrial  Computer  Systems  which  provides  the  impetus 
for  the  development  of  this  and  related  standards.  The  FORTRAN  Committee  is  chaired  by  Ms.  Maxine  N,  Hands;  General 
Chairman  of  the  International  Purdue  Workshop  is  Dr.  T.  J.  Williams. 

Committee  SPtil . Industrial  Computer  System  FORTRAN  Procedures  was  established  in  June  1971  as  a working  group  of  the 
FORTRAN  Committee  of  the  Purdue  Workshop  on  Standardization  of  Industrial  Computer  Languages  (later  reorganized  and 
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1 SCOPE 

This  standard  presents  external  procedure  references  for 
use  m industrial  computer  systems.  These  external 
procedure  references  permit  interface  of  programs  with 
executive  routines,  process  input  and  output  functions, 
allow  manipulation  of  bit  strings  and  provide  access  to 
time  and  date  information.  These  procedures  are  in- 
tended for  use  with  programs  written  in  FORTRAN  con- 
forming to  the  International  Standards  Organization 
( ISO ) Programming  Language- FORTRAN  R1539-1972.' 
expected  to  be  executing  both  in  a solitary  and  in  a 
multiprogramming  environment  under  the  control  of  a 
real  time  executive  routine. 

2 EXECUTIVE  INTERFACE 

2.1  Control  of  Program  Execution' 

Executive  interfaces  provide  the  facility  to  control 
operation  of  the  programs  within  the  system.  Through 
these  external  procedures,  one  may  start,  stop  or  delay 
the  execution  of  application  programs. 

The  argument  m,  shown  below,  shall  be  set  equal  to  or 
greater  than  two  (2)  in  value  for  all  instances  in  which 
the  request  is  not  accepted  by  the  executive  routine. 
Individual  implementations  may  specify  unique  values  of 
m within  the  allowable  range  to  designate  the  specific 
reason  for  which  the  request  was  rejected. 

2.2  Starting  a Program  Immediately  or 
After  a Specified  Time  Delay 

Execution  of  a referemt  e.  ihe  subroutine  START  shall, 
after  the  expiration  of  the  specified  time  delay,  cause 
the  execution  of  the  designated  program.  The  actual 
time  delay  obtainable  in  a specific  industrial  computer 
system  is  subject  to  the  resolution  of  that  system’s  real 
time  clock.  Execution  of  the  designated  program  will 
commence  at  the  program’s  first  executable  statement. 
The  form  of  this  call  is: 

CALL  START  |i,  j,  k,  m) 

where: 

i  specifies  the  program  to  be  executed. 

The  argument  is  either: 
a|  an  integer  expression 
or  b)  an  integer  array  name 
or  c)  a procedure  name 

The  processor  shall  define  which  of  the  above 
three  forms  is  acceptable. 

j specifies  the  minimum  length  of  time,  in  units  as 
specified  by  k,  to  delay  before  executing  the 
program.  If  the  value  of  j is  zero  or  negative,  the 
requested  program  will  be  run  as  soon  as  permis- 
sible This  argument  shall  be  an  integer  expression. 

k -peeifies  the  units  of  time  as  follows: 

0 basic  counts  of  the  system’s  real  time  clock 

1 Milliseconds 

1 ANSI  \ 19  I96fi  FORTRAN 


2 — Seconds 

3 — Minutes 

This  argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  program  to  indicate 
the  disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 — Request  accepted 

2 or  greater  — Request  not  accepted 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

2.3  Starting  a Program  at  a Specified  Time 

Execution  of  a reference  to  the  subroutine  TRNON  shall 
cause  the  designated  program  to  be  executed  at  a speci- 
fied time  of  day.  Execution  of  the  designated  program 
will  commence  at  the  program’s  first  executable  state- 
ment. The  form  of  this  call  is 

CALL  TRNON  (i,  j,  m) 

where: 

i specifies  the  program  to  be  executed. 

The  argument  is  either: 
a)  an  integer  expression 
or  b)  an  integer  array  name 
or  c)  a procedure  name 

The  processor  shall  define  which  of  the  above 
three  forms  is  acceptable. 

j designates  an  array  whose  first  three  (3)  elements 
contain  the  absolute  time  of  day  at  which  the 
specified  program  is  to  be  executed.  These 
elements  are  as  follows: 

First  element  Hours  (0  to  23) 

Second  element  — Minutes  (0  to  59) 

Third  element  — Seconds  (0  to  59) 

This  argument  shall  be  an  integer  array  name. 

m is  set  on  return  to  the  calling  program  to  indicate 
the  disposition  of  the  request  as  follows. 

The  value  must  be  1 or  greater 

1 — Request  accepted 

2 or  greater  — Requested  rejected 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

2.4  Delaying  Continuation  of  a Program 

Execution  of  a reference  to  the  subroutine  WAIT  shall 
return  after  a delay  of  a specified  length  of  time.  The 
form  of  this  call  is: 

CALL  WAIT  (j,  k,  m) 

where. 

j specifies  the  length  of  time  in  units  as  specified  by 
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k to  delay  before  returning  to  the  calling  pro- 
cedure. If  the  value  is  zero  or  negative,  no  delay 
will  occur.  Limitations  of  the  implementation  shall 
not  cause  the  precise  time  to  be  less  than  re- 
quested. This  argument  shall  be  an  integer 
expression 

k specifies  units  of  time  as  follows: 

0 — Basic  counts  of  the  system’s  clock 

1 — Milliseconds 

2 — Seconds 

3 - Minutes 

This  argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  program  to  indicate 
the  disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 — Request  accepted 

2 or  great!  r — Delay  as  specified  has 
not  occurred. 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

2.5  Program  Termination  Accomplished 
Using  Present  Standard 

Termination  of  programs  shall  be  accomplished  using  the 
STOP  statement  from  (ISO)  R1539  - 1972. 


3  PROCESS  INPUT/OUTPUT 
FUNCTION  INTERFACES 

3.1  Control  of  Analog  and  Digital 
Sensors  and  Outputs 

Process  input-output  function  interfaces  allow  access  to 
data  related  to  specific  analog  and  digital  sensors  and 
outputs.  The  execution  of  references  to  these  sub- 
routines will  result  in  return  only  being  made  to  the 
requesting  program  when  the  requested  data  transfer  is 
complete,  or  when  the  requested  operation  is 
terminated.  The  argument  m,  shown  below,  is  to  be 
interrogated  by  the  requesting  program  in  order  to  de- 
termine the  status  of  the  request.  An  individual  process- 
or may  specify  unique  values  for  m within  the  allowable 
range  to  designate  the  specific  error  conditions. 

The  results  of  the  input  operation  and  the  data  pre- 
sented for  output  operations  are  processor  dependent. 
The  operations  described  are  intended  to  be  unformat- 
ted transfers  to  and  from  the  specified  storage  in  the 
processor.  Therefore,  the  representation  in  the  storage  of 
the  processor  is  an  image  of  the  input  or  output  device 
specified. 


point  to  be  read  and  also  the  particular  form  of  all  the 
data  placed  in  the  array  k.  The  form  of  Ibis  call  is: 

CALL  AISQW  (i,  j,  k.  tn) 


i  specifies  the  number  of  analog  points  to  be  read. 
This  argument  shall  bean  integer  expression. 

j specifies  hardware  or  software  acquisition  and  con 
version  information.  Specific  information  relevant 
to  construction  of  this  argument  is  processor 
dependent  because  various  types  of  analog-to- 
digital  systems  are  available.  This  argument  shall 
be  either  an  integer  expression  or  an  integer  array 
name. 

k designates  an  array  to  which  the  values  am  as 
signed.  This  argument  shall  lie  an  integer  array 
name,  or  an  integer  array  element. 

m indicates  the  disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater. 

1 — All  data  collected 

2 — Operation  incomplete 

3 or  greater  — Error  conditions 

This  argument  shall  be  an  integer  variable  or  an 
integer  array  element. 

3.3  Analog  Inputs  in  any  Sequence 

Execution  of  references  to  this  subroutine  allows  the 
input  of  data  from  analog  points  in  a sequence  which  is 
independent  of  the  hardware.  This  may  also  be  referred 
to  as  the  input  of  analog  data  in  a random  order.  The 
array  j controls  the  input  sequence  and  allows  the 
specification  of  hardware  or  software  acquisition  and 
conversion  information  on  an  individual  point  basis.  The 
form  of  this  call  is: 

CALL  A1RDW  (i,  j,  k,  m) 


i specifies  the  number  of  analog  points  to  be  read. 
This  argument  shall  be  an  integer  expression. 

j specifies  hardware  or  software  acquisition  and  con 
version  information  for  each  analog  input  signal. 
Specific  information  relevant  to  construction  of 
this  argument  is  processor  dependent.  This 
argument  shall  lie  an  integer  array  name,  or  an 
integer  array  element. 

k designates  an  array  to  which  the  values  are  as- 
signed. The  order  of  the  elements  in  k will  cor 
respond  to  the  order  in  j.  This  argument  shall  lie 
an  integer  array  name,  or  an  integer  array  element. 


3.2  Analog  Inputs  in  a Sequential  Order 

Execution  of  a reference  lo  this  subroutine  allows  the 
input  of  data  from  any  number  of  analog  points  in  a 
sequence  which  is  specified  by  the  processors  input 
hardware  interface.  The  argument  j specifies  the  first 


m indicates  the  disposition  of  the  request  as  follows: 

The  value  must  he  1 or  greater 

1 — All  data  collected 

2 — Operation  incomplete 

3 or  greater  Error  conditions 
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This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

3.4  Analog  Output 

Execution  of  references  to  this  subroutine  allows  (he 
output  of  analog  signals  in  any  sequence.  The  form  of 
this  call  is: 

GAEL  AOVV  (i,  j,  k,  m) 

where: 

i  specifies  the  number  of  analog  points  to  be  writ- 
ten. Tnis  argument  shall  be  an  integer  expression. 

j specifies  hardware  or  software  conversion  and 
transmission  information  for  the  analog  output 
point.  Specific  information  relevant  to  con- 
struction of  this  argument  is  processor  dependent 
because  carious  types  of  digital-to-analog  systems 
are  available.  This  argument  shall  be  an  integer 
array  name,  or  an  integer  array  element. 

k designates  an  array  from  which  the  analog  output 
values  are  taken.  The  order  of  the  elements  in  k 
will  correspond  to  the  order  j.  This  argument  shall 
be  an  integer  array  name  or  integer  array  element. 

m indicates  the  disposition  of  tlie  request  as  follows: 

The  values  must  be  1 or  greater 

1 — All  data  outputted 

2 — Operation  incomplete 

.3  or  greater  - Error  conditions 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

3.5  Digital  Input 

Execution  of  references  to  this  subroutine  causes  the 
input  of  process  information  coded  as  a set  of  bits.  A set 
of  bits  is  typically  organized  and  read  as  an  external 
digital  word  whose  length  is  processor  dependent.  The 
form  of  this  call  is: 

CALL  DIW  (i,  j,  k,  m) 

where: 

i specifies  the  number  of  external  digital  words  (o 
be  read.  This  argument  shall  he  an  integer 
expression. 

j specifies  hardware  or  software  acquisition  and 
conversion  information  for  each  digital  input 
word.  Specific  information  relevant  to  con- 
struction of  this  argument  is  processor  dependent 
because  various  types  of  digital  inputs  are 
available.  This  argument  shall  be  an  integer  array 
name,  or  integer  array  element. 

k designates  an  arrav  to  which  the  requested  values 
arc  assigned.  The  order  of  (he  elements  in  k will 
correspond  to  the  order  in  j.  This  argument  shall 
he  an  integer  array  name,  or  integer  array  element 
name. 


m indicates  the  disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater. 

1 — All  data  collected 

2 — Operation  incomplete 

3 or  greater  — Error  conditions 

This  argument  shall  be  an  integer  variable  or 
integer  array  element . 

3.6  Momentary  Digital  Output 

The  execution  of  references  to  this  subroutine  causes  the 
output  of  momentary  digital  signals.  These  signals  con- 
sist of  sets  of  bits  typically  organized  as  an  external 
digital  word  whose  length  is  processor  dependent.  This 
type  of  output  is  characterized  by  an  action  which 
momentarily  sets  individual  outputs  when  a cor- 
responding bit  in  the  output  data  is  set.  These  output 
bits  will  then  be  reset  after  a specific  time  period.  The 
form  of  this  call  is: 

CALL  DOMW  (i,  j,  k.  n.  ml 

where: 

i specifies  the  number  of  external  digital  words  to 
be  written.  This  argument  shall  be  an  integer 
expression. 

j specifies  hardware  transmission  information  for 
each  word  of  output.  Specific  information  relevant 
to  construction  of  tiiis  argument  is  processor 
dependent  because  various  types  of  digital  outputs 
are  available.  This  argument  shall  be  an  integer 
array  name,  or  an  integer  array  element. 

k designates  an  array  whose  contents  are  the  image 
words  to  be  written.  The  order  of  the  elements  in 
k will  correspond  to  the  order  in  j This  argument 
shall  he  an  integer  array  name,  or  an  integer  array 
element. 

n specifies  the  duration,  measured  in  basic  system 
clock  counts,  that  the  outputs  are  to  remain  set.  If 
tlie  processor  does  no!  allow  selection  of  duration, 
this  argument  is  ignored  but  must  be  present.  Tins 
argument  shall  be  an  integer  expression 

m indicates  the  disposition  of  the  request  as  follows 

The  value  must  lx1  ] or  greater 

1 — All  outputs  accomplished 

2 — Operation  incomplete 

3 or  greater  — Error  conditions 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 

3.7  Latching  Digital  Output 

Execution  of  references  to  this  subroutine  causes  the 
output  of  digital  signals  which  can  bo  latched  in  either 
the  set  or  reset  slate.  These  signals  consist  of  sols  or  reset 
state.  These  signals  consist  of  sots  of  bits  typically  organ 
ized  as  an  external  digital  word  whose  length  is  processor 
dependent  This  type  of  output  is  characterized  by  an 
action  which  sets  individual  outputs  when  a eor 


. ... 


! 
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responding  bit  in  the  output  is  set  and  clears  individual 
outputs  when  a corresponding  bit  is  reset.  The  form  of 
this  call  is: 


CALL  DOLW  (i,  i.  kj.  k.,,  ml 


where  the  result  of  IOR  (j.  m)  is: 

l 2k  * (jk  * mk  - (jk  * mkl) 
k -0 


where: 


4.2.2  Logical  Product 


i specifies  the  number  of  digital  words  to  be  writ- 
ten. This  argument  shall  be  an  integer  expression. 

j specifies  hardware  transmission  information  for 
each  word  of  digital  output.  Specific  information 
relevant  to  construction  of  this  argument  is 
processor  dependent.  This  argument  shall  be  an 
integer  array  name,  or  an  integer  array  element 
name. 


The  fortti  of  this  function  reference  is: 
I AN  D (j.  m) 
where  the  result  of  IAND  (j.  m)  is: 

n k 

1 2k  * <jk  * mk) 

k=0 


k|  designates  an  array  whose  values  are  the  image 
words  to  be  output.  This  argument  shall  lx-  an 
integer  array  name,  or  an  integer  array  clement. 


4.2.3  Logical  Complement 

The  form  of  this  function  reference  is: 


k , designates  an  arrav  whose  values  define  digital 
outputs  which  can  be  changed  by  the  subroutine. 
A bit  set  in  the  k.,  array  indicates  tiiat  the  digital 
output  will  be  changed  to  the  state  defined  by  the 
corresponding  bit  position  in  the  corresponding 
integer  array  element  in  kj.  The  order  of  the 
elements  in  kj  and  kg  will  correspond  to  the  order 
in  j.  This  argument  shall  heart  integer  array  name, 
or  an  integer  array  element. 


NOT  (j) 

where  the  result  of  NOT  (jl  is: 

v 2k  * <l-jk) 
k=0 


4.2.4  Exclusive  Or 


m indicates  the  disposition  of  the  request  as  follows: 


The  form  of  this  function  reference  is: 


The  value  must  be  1 or  greater 

1 — All  outputs  accomplished 

2 — Operation  incomplete 

3 or  greater  — Error  conditions 

This  argument  shall  be  an  integer  variable  or 
integer  array  element. 


IEOH  (j,  m) 
where  the  result  of  IEOR  (j,  m)  is: 
n 

v 2k  * (2  - <jk  + mk))  * (jk  + mk) 
k=0 


4  BIT  STRING  MANIPULATION 

4.1  Types  of  Manipulation 

The  subprograms  which  follow  allow  the  programmer  to 
view  integer  data  as  ordered  sets  of  bits  (an,  an-t, 

up),  where  the  set  is  a place  positional  binary 

representation  of  an  integer  value,  thus  permitting  inter- 
rogation and  manipulation  of  integers  on  a bit-by-bit 
basis.  The  value  of  n is  processor  defined. 

4 2 Logical  Operations 

These  operations  are  external  functions.  In  the  following 
functions,  j and  m are  integer  expressions.  Operations 
are  performed  on  all  bits  which  represent  the  value  of  an 
integer  internal  to  the  processor.  Operations  are  done 
bit  by  bit  on  corresponding  bits,  that  is,  the  cor- 
responding bits  of  the  actual  arguments  j and  m are  used 
to  generate  the  integer  result . 

4.2.1  Inclusive  Or 

The  form  of  Ibis  function  reference  is: 

IOR  (j,  ml 


4.3  Shift  Operations 

This  operation  is  an  external  function.  In  the  following 
function  j and  tn  are  integer  expressions.  Operations  are 
performed  on  all  bits  which  represent  the  value  of  an 
integer  internal  to  the  processor,  and  are  used  to 
generate  an  integer  result. 

The  form  of  this  function  reference  is: 

1SHKT  (j.  m) 
where  the  result  of  ISHFT  (j,  in)  is: 

If  the  value  of  m is  positive  or  zero 
n-m 

v ->k  + m * i 

- Jk 

k 0 

If  the  value  of  m is  negative 
n 

v nkOn  * J(( 
k m 


4.4  Bit  Testing  and  Setting 

These  operations  are  external  functions.  In  the  following 
functions  j and  m are  integer  expressions. 

4.4.1  Bit  Test 

This  logical  function  tests  a specified  bit  of  an  integer. 
The  form  of  this  function  reference  is: 

BTEST  (j,  ml 
where  the  result  of  BTEST  (j.  ml  is: 

if  I AND  (j,2ml  0 then  FALSE,  else  TRUE 

4.4.2  Bit  Set 

This  function  sets  a specified  bit  of  an  integer. 

The  form  is  this  function  reference  is: 

IBSET  (j,  m) 

where  the  result  of  the  function  reference  IBSET  (j.  ml 

is: 

IOR  (j,  2n’> 

4.4.3  Bit  Clear 

This  function  clears  a specified  bit  of  an  integer. 

The  form  of  this  function  reference  is: 

IBCLR  |j.  m) 

where  the  result  of  the  function  reference  IBCLR  (j,  m) 

is: 

I AND  (j,  NOT(2m)) 

5 DATE  AND  TIME  INFORMATION 

5.1  Obtain  Time  of  Day 

Execution  of  references  to  this  subroutine  allows  a 
program  to  determine  tire  current  time  of  day.  The  form 
of  this  call  is: 

CALL  TIME  (j) 

where: 

I designates  an  integer  array  into  whose  first  three 
(3)  elements  the  absolute  time  of  day  will  be 
placed.  Tile  contents  of  these  elements  shall  be  as 
follows: 

Firsi  Element  Ilnurs  0 to  23 

■second  Element  Minutes  (I  to  50 

Third  Element  Seconds  0 to  59 

5.2  Obtain  Date 


program  to  determine  the  current  calendar  date.  The 
form  of  this  call  is: 

CALL  DATE  ()> 

where: 

j designates  an  integer  array  into  whose  first  three 
(3)  elements  the  date  will  be  placed  The  contents 
of  these  elements  shall  be  as  follows: 

First  Element  — AD  year  since  zero 
Second  Element  — Month  1 to  12 
Third  Element  — Day  1 to  31 


APPENDIX  A 

(This  appendix  is  not  part  of  the  ISA  Standard  S61  1. 
but  is  included  to  facilitate  its  use  I 

Considerations  leading  to  "ISA-S61.1  Industrial  Com 
puter  System  FORTRAN  Procedures  for  Ex-eutiv. 
F’unctions  Process  Input  Output,  and  Bit-Mampulat  oi. 

A.1  Historical  Development 

This  standard  is  a direct  outgrowth  of  the  International 
Purdue  Workshop  on  Industrial  Computer  Systems 
whose  goals  are: 

To  make  the  definition,  justification,  hard 
ware  and  software  design,  procurement 
programming,  installation,  commissioning, 
operation  and  maintenance  of  industrial 
computer  systems  more  efficient  and 
economical  through  the  development  of 
standards  and/or  guidelines  oil  an  interna 
tional  basis. 

The  Workshop  formed  several  committees  to  achieve 
their  objectives.  The  FORTRAN  Committee  was  charged 
with  the  task  of  preparing  a set  of  Industrial  Process 
Standards  compatible  with  FORTRAN  as  defined  b\ 
ISO-R1539-I972.  This  standard  is  a result  of  that  com 
mittee’s  work.  Additional  standards  are  being  doveh  ped 

A. 2 Criteria  Used  in  Developing  This  Standard 

The  committee  assessed  that  FORTRAN  was  the  most 
widely  used  language  in  the  industrial  environment  It 
thus  used  the  following  guidelines  in  the  development  of 
the  standard. 

1 The  standard  should  cover  features  commonly  used 
by  existing  industrial  computer  systems. 

2.  The  standards  should  be  easy  to  implement  for  most 
vendors. 

3.  The  standards  should  follow  the  syntax  and  intent  of 
FORTRAN  as  defined  b\  ISO. 

I.  The  standards  should  not  reslrirt  the  future  evolution 
of  FORTRAN. 

The  development  of  the  FORTRAN  language  is  present 
ly  the  responsibility  of  ISO  who  has  delegated  I Ins  re 
sponsibility  to  ANSI  X3J3. 

In  order  dial  these  standards  comply  with  the 
ISO-R1 539-1972  standard  as  far  as  possible,  external 


Execution  of  references  to  this  subroulinr  allows  a 
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; 


proeeduri  references  were  us'd  rather  than  direct 
i hange'  or  additions  to  the  syntax  of  FORTRAN.  lhis 
. not  imply  that  I his  is  the  only  wav  to  provide  these 
atun  s nor  dm  s :t  exclude  the  possibility  or  desirability 
that  the  language  will  be  developed  through  syntax 
change  so  that  these  features  and  other  related  features 
can  be  performed. 

APPENDIX  8 

\ Ibis  appendix  is  not  part  of  the  ISA  Standard  Stil  l, 
but  is  included  to  facilitate  its  use.i 
NOTES  BY  SECTION 

B I Section  ? Notes 

l his  standard  is  a permissive  standard  in  that  it  does  not 
preseritie  how  the  executive  will  respond  to  external 
procedure  reierences  nor  does  it  describe  how  the  in- 
form. dion  is  passed  to  tile  executive  routine.  In  par 
ticular.  the  argument  "i  in  FALL  START  (2.21  and 
l VI. L IRNON  (2. .'ll  lets  three  forms,  an  integer  ex- 
pression, an  inleg  r array  name  or  a program  name,  only 
one  of  vvhieh  is  permissible  in  any  particular  program, 
[his  restrielion  is  a necessary  consequence  of  the  re 
quiren’.c:  . of  tie  FORTRAN,  language  that  any  argu- 
ment which  is  an  external  proeeduri  reference  be  of  a 
defined  type;  integer  expressions,  integer  array  names 
and  program  name-  are  different  ty  pes  iSeetion  S.  1.2  ol 
1SO-K1539  '7  it  is  also  a consequence  of  the 

I- OR  TRAY  lai.g  a.  that  if  the  argument  is  a program 
name,  this  name  must  appear  in  an  EXTERNAL  state- 
ment (Section  7.2.16  if  ISO-R1539-1972). 

I. sample,  of  tiie  use  of  the  argument  i its  an  integer 
expression  are. 

CALL  START  (7.0, 0.M) 

DATA  .1  7 

CALL  START  (J.O.O.Ml 

DATA  J/2J1AB/ 

CALI,  START  (J,0,0,M) 

An  example  of  the  use  of  the  argument  i as  an  integer 
array  name  is; 

INTEGER  XYZ 
DIMENSION  XYZ  (3) 

DATA  XYZ(l),  XYZ(2),XYZ(3)/2HAB.2HCD.2HEF 
CALL  START  (XYZ.O.O.MI 

An  example  of  the  use  of  the  argument  i as  a procedure 
name  is: 

EXTERNAL  A BCD 

CALL  START  (ABCD,0,0.M) 

Interchangeability  of  programs  between  different 
processors  is  reduced  by  permitting  three  possible  types 
for  this  argument  but  the  committee  feels  if  is  premature 
lo  standardize  to  achieve  full  interchangeability  in  this 
area. 

B.2  Section  3 Notes 

As  an  extension  to  the  process  I/O  calls,  six  additional 
calls  may  he  defined.  They  an-  AlSt),  AIK  I),  AO,  1)1. 
IKlM.  DOI..  Processors  conforming  to  ISO  K 1539-1 1*72 


require  extensions  to  support  these  calls;  namely,  the 
FORTRAN  processor  must  maintain  association  with 
the  data  block  during  execution  of  these  subroutines  by 
the  executive  routine.  These  calls  accommodate  execu 
live  routines  which  permit  continuation  of  execution  in 
the  requesting  program  while  the  process  input  or  out 
put  is  being  accomplished.  These  arc  related  to  the  six 
standard  calls  as  shown  below; 


STANDARD 

EXTENSION 

ALSQVV 

Aisy 

AIRDW 

AIRD 

AIW 

A I 

DIW 

Dl 

DOMW 

DOM 

DOLW 

DOL 

wherein  the  arguments  are  defined  identically  as  those  ol 
the  corresponding  standard  calls. 

For  these  extensions,  the  requesting  program  is  required 
lo  have  provision  for  periodically  testing  the  status  of 
tiie  request.  This  is  accomplished  by  use  of  the  argument 
m. 

All  values  returned  by  these  extensions  should  not  lie 
considered  as  defined  until  such  time  as  the  parameter  m 
indicates  operation  completed  or  error  condition. 

The  process  system  designer  must  ensure  Ihe  availability 
of  these  arguments  to  the  process  input/output  interfaei 
subroutine  in  his  total  system.  No  method  is  given  of 
how  this  will  be  achieved,  although  most  existing  in- 
dustrial systems  have  features  which  can  be  used  for  this 
purpose,  such  as  global  common. 

For  the  standard  process  I/O  calls,  the  return  to  (In- 
calling  program  should  not  bo  made  with  ni'2.  On 
return  m should  equal  1 to  indicate  successful  comple- 
tion or  m should  be  3 or  greater  to  indicate  an  error  was 
found. 

The  argument  j is  defined  to  be  processor  dependent  and 
can  take  several  different  forms.  For  example,  in  AISQH 
and  AIRDW 

1.  An  alias  for  the  analog  input  similar  to  a logical  unit 
number 

2.  A one  word  per  analog  input  hardware  address 

3.  A multiple  word  per  analog  input  hardware  address  in 
which  case  the  arrav  j must  he  a multiple  of  the  si/e 
or  k. 

B.3  Section  4 Notes 

The  basic  unit  of  computer  storage  is  the  integer  accord 
ing  to  ISO  FORTRAN.  For  the  purposes  of  industrial 
computing  it  is  necessary  to  view  integer  data  as  an 

ordered  set  of  bits  |an,  o„_  j Uq)  where  the  set  is 

a place  positional  binary  representation  of  an  integer 
value. 

For  reasons  of  mathematical  exactitude  it  is  necessary  to 
express  the  hit  functions  as  a summation  of  a series,  hut 
on  a "normal”  two's  complement  binary  computer,  they 
will  operate  in  the  expected  manner  for  such  functions 
However,  on  a binary  coded  decimal  machine  the  results 
of  these  functions  may  not  Im-  in  the  exported  manner 
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forsuch  functions  and  it  will  not  be  possible  to  reference 
every  'bit'  of  a word 

Items  such  as  difference  in  word  lengths,  one’s  com 
plement  versus  two’s  complement,  negative  numbers  and 
BCD  versus  pure  binary  will  affect  transportability. 
However,  due  to  the  differences  in  the  computers  them 
selves,  these  differences  are  to  be  expected. 

These  functions  are  not  intended  to  discourage  the  in 
troduction  of  syntactic  changes  to  FORTRAN 

B.3.1  Examples  of  Section  4 

The  following  examples  illustrate  the  use  of  Section  1 in 
less  mathematical  terminology  The  processor  is  assumed 
to  be  a seven  (7)  bit  +,  two’s  complement  machine,  with 
the  sign  hit  on  the  extreme  left. 

let  j 10  (0001010) 

m 3 (0000011) 


IOR  (|. mi  1 1 

(0001011) 

lAND(j.ni)  2 

(0000010) 

NOT  (j)  11 

I 1 1 10101 1 

IKOK  (j.nn  9 

(0001001 i 

ISM  FT  (j.m)  IK 

1 10100001 

1SHFT  ().  ml  1 

(0000001 1 

ISHF’T(m,j)  0 

( 0000000 l 

BTEST  ij.m)  TRUE 

IBSKT  (j.m)  10 

(0001010) 

IHCl.RO.m)  2 

(0000010) 

B.4  Section  5 Notes 

The  format  used  for  referencing  time  and  date  follows 
the  ISO  standard  K 20 14-1071 . writing  of  calendar  dates 
in  all-numeric  form. 

The  standard  ISA-Stil.l  does  not  define  the  base  used 
or  how  the  processor  maintains  date  and  time  but  does 
define  how  this  information  is  made  available  to  the 
program. 
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SECTION  II 

Proposed  ISA  Standard  S61.2 

INDUSTRIAL  COMPUTER  SYSTEM  FORTRAN  PROCEDURES 
FOR  FILE  ACCESS  AND  THE  CONTROL  OF  FILE 
CONTENTION 


Developed  by  the  Industrial  Real-Tinie  FORTRAN  Committee 
of  the  Workshop  through  ISA  Standards  Committee  SCSI.  Presently 
under  review  by  ISA  Standards  Review  Procedures.  As  presented 
here  it  is  substantially  correct.  The  only  likely  technical 
change  is  an  additional  access  privilege  called  PROTECTED 
READ.  Approval  by  ISA  is  expected  early  in  1977. 


I 
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PREFACE 


This  forward,  all  footnotes  and  all  Appendices  are  included  for  informational  purposes  and  are  not 
part  of  Standard  ISA-S61.2. 

This  Standard  has  been  prepared  as  a part  of  the  service  of  the  Instrument  Society  of  America  toward 
a ooal  of  uniformity  in  the  field  of  instrumentation.  To  be  of  real  value  this  document  should  not 
be  static  hut  should  be  subjected  to  periodic  review.  Toward  this  end  the  Society  welcomes  all  comments 
and  criticisms  and  asks  that  they  be  addressed  to  the  Standards  and  Practices  board  Secretary,  Instrument 
Society  of  America,  400  Stanrix  Street,  Pittsburgh,  Pennsylvania,  15222. 

The  ISA  Standards  and  Practices  Department  is  aware  of  the  growing  need  for  attention  to  the  metric 
system  of  units  in  general,  and  the  International  System  of  Units  (SI)  in  particular,  in  the  preparation 
of  instrumentation  standards.  The  Department  is  further  aware  of  the  benefits  to  users  of  ISA  Standards 
in  the  U.S.A.  of  incorporating  suitable  references  to  the  SI  (and  the  metric  system)  in  their  business 
and  professional  dealings  with  other  countries.  Toward  this  end  this  Department  will  endeavor  to 
introduce  SI  and  Si-acceptable  metric  units  in  all  new  and  revised  standards  to  the  greatest  extent 
possible.  The  Metric  Practice  Guide,  which  has  been  published  by  the  American  Society  for  Testing  and 
Materials  as  ANSI  Z210.1  (ASTM  E380-76),  and  future  revisions,  will  be  the  reference  guide  for 
definitions,  symbols,  abbreviations  and  conversion  factors. 

The  ISA  Standards  Committee  on  Industrial  Comnuter  System  FORTRAtl  Procedures  for  Executive  Functions 
and  Process  Innut-Output  SPB1  , operates  within  the  ISA  Standards  and  Practices  Department,  W.  B.  Miller, 
Vice  President.  The  persons  listed  below  served  as  members  of  this  Committee: 


Scott  Paper  Company 
IBM  Corporation 
Modular  Computer  Systems 
Foxboro  Company 
Inland  Steel  Company 
ALCOA 

Hewlett-Packard 
Westinghouse  Electric  Company 
Honeywell,  Inc. 

Datum  Inc. 

Union  Carbide 
Johnson  Service  Company 
Stanford  University 
Tennessee  Eastman  Company 
General  Electric 


1 


Copyright  197C  by  the  Instrument  Society  of  America 


M.  R.  Gordon-Clark,  Chairman 
A.  Arthur 
F.  E.  Bearden 
R.  Caro 

L.  Cartright 
R.  L.  Curtis 
W.  Van  Diehl 
J.  Froggatt 
D.  Frost 
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C.  C.  Haskel 
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Industrial  Comouter  System  FORTRAN  Procedures  for 
File  Access^  and  _the  Control  of  File  Contention 


COPF 


2.  INTERFACES  TO  ACCESS  FILES 


Inis  standard  presents  external  procedure 
references  for  use  in  industrial  computer  control 
/stems . These  external  procedure  references 
provide  mean s for  accession  files,  and  also 
provide  leans  for  resolvinn  problems  of  file 
access  contention  in  a nul t i programni rtg/mul ti- 
processim  environment.  In  a multiprogramming/ 

’ ultiprocessinq  environment,  it  is  expected  that 
concurrent  proqrams  will  attemnt  to  access  the 
same  file  at  the  sane  time,  therefore,  the 
external  nrocedure  references  defined  in  this 
standard  provide  the  information  necessary  for 
the  processor  to  resolve  such  simultaneous 
access  in  an  orderly  manner.  The  method  for 
resolution  of  access  control  is  left  to  the 
processor. 

1.1  Definition 

File:  A collection  of  related  records  treated  as 

a unit.  For  the  purposes  of  this  standard, 
records  are  viewed  as  being  of  fixed  lenoth. 

Record  -toraqe  and  access  are  independent  of  the 
internal  format  of  records. 

1.2  Cackground 

In  computing  systems,  individual  programs  may  have 
various  relationships: 

- Programs  are  executed  sequentially. 

- Several  programs  can  be  operating  concurrently 
but  with  no  shared  resources. 

- Several  programs  can  be  operating  concurrently 
and  these  concurrent  programs  may  share  resources. 
A file  can  be  such  a shared  resource. 

Files  exist  in  all  computing  systems  and  can  have 
various  attributes  and  features,  such  as: 

- A file  can  contain  data,  nrograms,  or  catalogue 
i nfomation . 

- There  can  be  a variety  of  ways  for  file  access 
such  as  sequential,  direct,  and  stream. 

- A file  can  be  created  or  deleted  by  a program, 
by  a system  utility,  nr  at  system  generation 
time. 

A file  can  have  security  attributes  associated 
with  the  file  for  the  purnose  of  ensuring  file 
privacy. 

- When  a file  is  associated  with  a program,  this 
association  can  be  restricted  by  the  processor 
for  reasons  of  orivacy. 

- A file  can  be  associated  with  a set  of  related 
concurrent  programs  and  this  association  can 
lie  restricted  to  assure  orderly  resolution  of 
contention  problems  among  the  concurrent  programs. 
A file  can  be  internal  or  external  to  a program. 

- A file  can  reside  on  fixed  or  removable  media. 

- A file  can  reside  on  main  storage  or  backing 

storage. 

- Restrictions  for  reasons  of  privacy  or 
contention  may  apply  to  a file  or  a component 
of  a file  such  as  records  and  data  items. 


2.1  File  System  Environment  For  This  Standard 

In  industrial  computer  systems,  concurrent  program 
oueration  with  shared  resources  such  as  files  is 
a common  occurrence.  This  standard  Noes  not 
address  all  the  areas  of  file  management  but  is 
concerned  with  the  nroblems  that  most  commonly 
arise  in  industrial  computer  systems. 

Table  1 shows  both  those  features  covered  by  the 
standard  and  those  excluded;  however  the  excluded 
features  may  affect  the  result  of  a request  for 
association  of  a concurrent  program  to  a file. 

Such  restrictions  on  associations  are  processor 
dependent  and  are  outside  the  scope  of  this  standard. 

The  argument  m,  shown  below,  shall  be  set  equal  to 
or  greater  than  two  (2)  in  value  for  all  instances 
in  which  the  request  is  not  accepted  by  the 
executive  routine.  Individual  implementation  may 
specify  unique  values  of  m within  the  allowable 
range  to  designate  the  specific  reason  for  which 
the  request  was  rejected. 

2.2  Create 

Execution  of  a reference  to  the  subroutine  CFILW 
shall  establish,  but  not  open,  a named  file.  Files 
established  by  CFILW  do  not  have  any  privacy 
attribute  to  restrict  a concurrent  program  from 
accessing  the  files.  The  form  of  call  is: 

CALL  CFILW  ( j,ni ,n2»m)  where: 

j specifies  the  file 

The  argument  is  either:  a)  an  integer  expression 

or  b)  an  integer  array  name 

or  c)  a procedure  name 

The  processor  shall  define  which  of  the  above 
three  forms  are  acceptable. 

n l specifies  the  number  of  integers  per  record 
in  this  file.  This  argument  shall  be  an 
integer  expression. 

n2  specifies  the  number  of  records  in  this  file. 

This  argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  program  to 
indicate  the  disposition  of  ttie  request. 

The  value  must  be  1 or  greater 

1 - File  successfully  created 

2 or  greater  - File  not  created 

This  argument  shall  be  an  integer  variable 
name  or  integer  array  element  name. 

2.3  Delete 

Execution  of  a reference  to  the  subroutine  DFILW 
shall  remove  a file  from  the  file  system.  Any 
file  created  by  the  mechanism  of  Section  2.2  can 
be  deleted  by  the  execution  of  a reference  to 
DFILU.  A file  currently  open  to  another  program 
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TABLE  I 

FEATURES  AflD  ATTRIBUTES  OF  FILLS 


Included  In  Standard 

- Files  whose  contents  are  considered  to  be  data. 

- Files  which  exist  on  fixed  media  only  or  on 
removable  media  which  are  not  removed. 

- Files  which  reside  in  main  storage  or  in 
backing  storage. 

- Files  which  are  external  to  a concurrent 
program. 

- Creation  and  deletion  of  files  by  a concurrent 
p rog  ram . 

- The  association  of  a file  to  a concurrent 
program  for  both  system  created  and  for 
concurrent  program  created  files. 

- Restrictions  on  file  access  as  applied  to  the 
file. 

- The  association  of  a file  to  a concurrent 
program  irrespective  of  the  method  of  access 
(direct,  sequential  c ■ stream). 

- Read  and  write  methods  of  access  for  direct 
access  files  only  (sequential  files  are 
covered  by  standard  FORTRAN  ISO  R1539-1972). 


Excluded  From  Standard 

- Files  whose  contents  are  not  considered  to  be 
data  by  the  accessing  concurrent  program. 

- Files  which  exist  on  removable  media  whicn  are 
removed. 


- Files  which  are  internal  to  a concurrent  program 


- Creation  and  deletion  of  files  by  a system 
utility  or  at  system  generation. 


- Restrictions  on  file  access  a:  applied  to  a 
component  of  a file. 


- Methods  of  file  access  except  for  direct  access. 


- Attributes  of  a file  for  the  purpose  of  ensuring 
file  privacy. 


L.  _ 


• • i >-f  of  this  call  Is: 


•■it  '-r:  a)  jn  integer  expression 

o.  . ) «r  integer  array  name 
or  c)  a procedure  name 
■all  define  which  of  the  above 


- I 


a re  omen  t 


1 ■ , . > ‘nail  djfine  which  of  the  above 

tnrce  foriis  art  acceptable. 

r is  set  on  r tun  to  the  calling  prour;  • to 
e di;  ■ re  ui  l . 

The  val  i e must  bo  1 or  greater 

1 - i 'It  successfully  deleted 

2 or  roster  - File  not  deleted 

Tins  argument  shall  be  an  integei  variable 
ra  or  integer  array  elei  i nt  name. 

2.4  Open 

Erection  of  a re  orence  to  tlie  subroutine  0PE1IW 
shall  associate  the  specified  logical  unit  by 
tlie  program  with  a nancd  file,  and  shall  define 
toe  desired  access  privilege  of  that  program  to 
the  file.  The  form  of  this  call  is: 

CALL  OPET.I  (i,j,k,m)  where: 

specif  . the  logical  unit  number  of  which 
t ■ •'  !<.  n : bv  the  argument  j is  referenced 

”,  tne  progrn;  . '"his  a > ] umen t shall  be  an 
Integer  expression. 

j sped firs  the  f i le. 

Toe  argument  is  cither:  a)  an  integer  expression 

or  b)  an  integer  array  narie 
or  c)  a procedure  name 
lit  f i which  of  the  above 

tnr-ee  forms  are  acceptable. 

spec  :i  - .-s  the  desirnc,  access  privilege  under 
w ich  t:;c  program  wishes  Co  receive  the  file 
and  is  a declaration  of  intended  use  by  the 
pronra  . Tnis  argument  shall  be  an  integer 
expression. 

V..  following  values  are  defined: 

1 Read  Only  - The  calling  program  can 
read  but  not  write;  other  concurrent 
programs  can  read  and  write. 

2.  hared  - . calling  program  can  read  or 

rite;  other  concurrent  programs  can 

reati  or  write. 

3.  Exclusive  Write  - The  calling  program 
can  read  or  write;  other  concurrent 
programs  can  only  read. 

4.  Exclusive  All  - Only  the  calling  program 
can  acc'ss  the  file. 

i set  on  return  to  me  colling  program  to 
indicate  the  disposition  of  the  reguest. 

The  value  must  be  1 or  greater. 

1 - File  successfully  opened  to  the  calling 
program 

2 or  greater  - File  not  open  to  the  calling 
program 
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This  argument  .tall  be  an  i n t • -ye r variable 
name  or  integer  array  ek  .ent  name. 


L i ndtat i ons 

If  the  til  r currently  Open  to  another  [ •oqrai.  , 
the  disposition  of  a nossible  request  for  a 
particular  access  privilege  will  be  as  follows 

- Read  Only  - fails  if  mother  program  currently 
has  Lxclusive  All  privilege,  otherwise  succeeds 

- Shared  - Fai’,  if  another  prograi  currently 

has  Exclusive  All  or  Exclusive  Write  privileges, 
otherwise  succeeds 

- Exclusive  Write  - Fail'  if  another  pregrar 
currently  has  exclusive  All,  Exclusive  ..rite, 
or  Shared  privileges,  otherwise  succeeds. 

- Exclusive  All  - Fails 

Any  attempt  to  open  a file  will  be  successful  ml/ 
if  the  file  exists.  If  tiie  file  was  created  Ly 
a mechanism  outside  of  the  standard,  the 
attribute:,  given  to  the  file  at  its  creation  ' ay 
iesti  ct  the  granting  of  an  a^CuS'  privili.gi  t< 
the  program. 

2.5  lose 

Execution  of  a reference  to  tne  suhiouti.it  CLj'-LW 
shall  end  the  program  association  of  tne  lec.fied 
logical  unit  with  a named  file.  Tnis  association 
will  have  been  established  by  the  execution  of  a 
previous  OPENW  call.  The  fori:  of  the  call  is: 

CALL  CLGSEW  (i,rn)  where: 

i specifies  the  logical  unit  number.  Ttii 
argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  progra.  to 
indicate  the  disposition  of  the  request. 

The  value  must  be  1 or  greater 

1 - File  successfully  closed  to  the  prograi 

2 or  greater  - Non-performance 

This  argument  shall  bo  an  integer  variable 
name  or  integer  array  element  name. 

2.6  Modify  Access  Privileges 

Execution  of  a reference  to  the  subroutine  fiUDAPW 
shall  change  the  calling  program's  acts  privilege 
to  a previously  openea  file  without  closing  and 
reopening  the  file. 

Ii  the  request  for  change  cannot  b>  granted,  tne 
pri  ions  access  privilege  remains  in  forci  1 
form  of  thi s cal  1 is : 

CALL  IIOuAPW  (i,k  ,m)  where: 

i ; it  logical  t nu  r. 

argument  sliall  be  an  integer  express  inn. 

k specifies  tor  tc.cess  privilege  desired.  This 
argument  shall  be  an  integer  expression. 

The  following  values  are  defineu: 

I Read  Only  - no  calling  prograi  ..A<  read 
but  nut  write;  other  concurrent  prograi  • 
can  read  or  write. 


1 
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2  Shared  - The  calling  program  can  read  or  the  file  and  must  currently  have  access  privileges, 

write;  other  concurrent  programs  can  also 

read  or  write.  CALL  RDRW  (i,j,k,n,n)  where: 


3 Exclusive  Write  - The  calling  program  can 
read  or  write;  other  concurrent  programs 
can  only  read. 

4 Exclusive  All  - Only  the  calling  program 
can  access  the  file. 

m is  set  on  return  to  the  calling  program  to 
indicate  the  disposition  of  the  request. 

The  value  must  be  1 or  greater. 

1 - Access  privileges  requested  is  granted 
to  the  program 

2 or  greater  - Access  privileges  before  the 
request  remains  in  force 

This  argument  shall  be  an  integer  variable 
name  or  integer  array  element  name. 

Limi tations 

If  the  file  is  currently  open  to  another  program, 
the  disposition  of  a request  for  a particular 
access  privilege  will  be  as  follows: 

- Read  Only  - Fails  if  another  program  currently 
has  Exclusive  All  privilege,  otherwise  succeeds 

- Shared  - Fails  if  another  program  currently 

lias  Exclusive  All  or  Exclusive  Write  privileges, 
otherwise  succeeds. 

- Exclusive  Write  - Fails  if  another  program  lias 
Exclusive  All,  Exclusive  Write,  or  Shared 
privileges,  otherwise  succeeds 

- Exclusive  All  - Fails 

If  the  file  was  created  by  a mechanism  outside 
of  the  standard,  the  attributes  given  to  the  file 
at  its  creation  may  restrict  the  granting  of 
an  access  privilege  to  the  program. 


3.  I11PUT/0UTPUT  TO  UNFORMATTED 
DIRECT  ACCESS  FILES 

Various  methods  of  accessing  files  exist  such  as 
"sequential"  and  "direct."  Direct  access  is  a 
method  in  which  items  of  information  are  stored 
and  become  available  independently. 

This  section  of  the  standard  provides  for 
unformatted  direct  access  to  files.  Access  to 
sequential  files  is  defined  by  ISO  R1539-1972. 

In  this  standard,  direct  access  files  are 
considered  to  consist  of  fixed  lenqtli  records. 
These  files  are  considered  to  be  resident  in 
some  mass  memory  that  is  permanently  attached 
to  the  computer.  The  length  of  a record  in 
these  files  is  defined  in  terms  of  a unit  which 
is  the  amount  of  storage  occupied  by  one  integer. 

3.1  Direct  File  Read 

The  execution  of  a reference  to  the  subroutine 
RDRVi  results  in  the  sequential  transfer  of  one 
data  record  from  a file.  The  file  is  treated 
as  a direct  access  file  for  selection  of  the 
record.  The  calling  program  must  have  opened 


i specifies  the  logical  unit  number.  This 
argument  shall  be  an  integer  expression. 

j specifies  the  record  number  of  the  record  to 
be  read.  This  argument  shall  be  an  integer 
expression. 

k designates  the  first  variable  into  which 
information  is  to  be  placed.  This  argument 
shall  be  a)  an  integer  variable  name  or 
integer  array  element  name  or  b)  integer  array 
name. 

n specifies  the  maximum  number  of  integers  tnat 
can  be  transferred. 

m is  set  on  return  to  the  calling  program  to 
indicate  the  disposition  of  the  request. 

The  value  is  1 or  greater 

1 - Data  transfer  completed  successfully. 

2 or  greater  - Data  transfer  fails. 

The  argument  shall  be  an  integer  variable 
name  or  integer  array  element  name. 

3.2  Direct  File  Write 

The  execution  of  a reference  to  the  subroutine 
WRTRW  writes  unformatted  direct  accessed  information 
into  files  which  have  previously  been  opened  and 
access  privileges  assigned  to  the  calling  program. 
The  request  will  only  be  successful  if  the  program's 
access  privilege  is  shared,  exclusive  write  or 
exclusive  all. 

Ttie  forms  of  the  calls  are: 

CALL  WRTRW  (i,j,k,n,m) 

This  call  is  identical  to  RDRW  except  for  tue 
direction  of  information  transfer. 


I 
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These  Appendices  are  not  part  of  the  ISA  Standard 
St>  1.2  hut  are  included  to  facilitate  its  use. 


APPENDIX  A 

Considerations  leading  to  Industrial  Computer 
yste".'  FORTRAN  Procedures  for  File  Access. 

T 1 Historical  Development 

r.hi  standard  is  a direct  outgrowth  of  the 
International  Purdue  llorkshop  on  Industrial 
Computer  Systems  whose  goals  are: 

To  mate  the  definition,  justi f ication , hardware 
and  software  (lesion,  nrocurement,  program li nrj , 
installation,  comissioning,  operation  and 
maintenance  of  industrial  computer  system  more 
efficient  and  economical  throuon  the  development 
rf  standards  and/or  guidelines  on  an  international 
basis. 

The  Workshop  formed  several  committees  to  achieve 
its  objectives.  The  Fortran  Language  Committee 
was  cnarged  with  the  task  of  preparing  a set  of 
Industrial  Process  standards  compatible  with 
FORTRAN  as  u<; fined  by  ISO  R1 539—1 972* . 

This  standard  is  the  result  of  that  committee's 
work. 

A. 2 Criteria  Used  in  Developing  F0PJRA1I  Standards 

The  committee  assessed  tne  status  of  FORTRAN  as 
used  in  the  industrial  environment  and  followed 
the  guidelines  below  in  the  development  of  the 
standards : 

(1)  The  Standards  should  cover  features  commonly 
used  by  existinq  industrial  computer  systems. 

(2)  Tne  standards  should  he  easily  implemented 
liy  most  vendors. 

(3)  The  standards  should  follow  the  syntax  and 
intent  of  FORTRAN  as  defined  bv  ISO  RI539- 

1972. 

(4)  The  standards  should  not  restrict  the  future 
evolution  of  FORTRAN . 

The  development  of  FORTRAN  standards  is  presently 
tne  responsibility  of  ANSI/X3J3.  In  order  that 
ISA  standards  comply  with  the  ANSI  standards  as 
far  as  possible,  external-procedure  references 
'■ere  used  rather  than  direct  changes  or  additions 
to  tne  syntax  of  FORTRAN.  This  does  not  imply 
that  this  is  the  only  way  to  provide  these 
features,  nor  does  it  exclude  the  possibility  or 
desirability  that  ANSI  will  develop  the  language 
v/ntax  to  perform  these  and  other  related  forms. 


APPLNDIX  L 
NOTES  BY  SECTION 
D.l  Section  2 Notes 

This  standard  is  a permissive  stanuaru  in  teat  it 
does  not  prescribe  how  the  executive  will  respond 
to  the  external  procedure  references  nor  hov  tne 
information  on  the  access  privileges  to  tne  file 
will  be  handled  by  tne  executive  routine.  Intir- 
changeabi  1 i ty  of  programs  among  (Afferent  processors 
with  different  executive  routines  is  reduced  uy 
this  lack  of  prescription  but  the  committee  fee  Is 
that  it  is  premature  to  standards  to  the  degree 
necessary  to  achieve  this  interchangeability. 

This  standard  does  nut  cover  all  areas  f file 
Management.  In  particular  no  altei,i|  l is  i aue  to 
consider  file  privacy.  In  an  industrial  computer, 
system  privacy  is  not  a significant  proulem 
because  tne  intent  is  to  provide  a common  data 
base  on  plant  operation  for  control  and  information 
purposes  for  all  users  of  the  system  but  tne  grobleti 
of  contention  is  acute  because  of  tne  asynchronous 
nature  of  ttie  requests  to  tne  system. 

Tile  Management  can  be  very  complex  especinlly 
with  removable  media  because  tne  systei  must 
check  that  the  correct  media  is  present  for  all 
assess  to  the  file.  Sucn  checking  involveu 
considerable  system  overhead  wiiicn  is  much  reuucie 
if  a restriction  is  made  to  non-removable  media. 

The  committee  consiuers  tiie  restriction  to  non- 
removable- media  satisfactory  for  inuustridl  system, 
especially  if  adequate  measures  are  taken  uy  tne 
operators  of  the  equipment  at  tnose  times  vmen 
removable  media  are  changtu. 

lil . 1 Lxample 

Consider  a file  called  FILiiAFi  which  contains  uata 
on  a process.  The  file  is  eight  (El)  records  long, 
eacli  record  contains  ten  (10)  integers.  Tne  first 
seven  (7)  records  contain  process  information,  tni 
eigth  record  contains  status  information. 

Program  AbC  reads  the  process  uata  in  me  first 
seven  records  of  FILI1AI1  ana  sets  tne  process  data 
in  the  first  seven  records  of  FILiiAI.  and  sets  up 
the  status  information  on  the  eighth  record. 

Program  XYZ  reads  the  status  record  of  FILIIAH, 
performs  some  actions,  and  resets  tne  status  rtcoru. 

Program  AbC  is  executed  asynchronously  wnen  tne 
process  information  changes.  I'rooran  XYZ  runs 
at  regular  intervals. 

In  this  example  the  file  contention  procedures  art- 
used  to  ensure  an  orderly  use  of  tne  status 
information  of  the  file  FILliAM. 


* 1 TO  R1 539-1972  is  the  sane  as  ANSI  X3. 9-1966. 
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C example  program  ABC 

INTEGER  FILNAM 

DIMENSION  I VAL (10),  JVAL(IO) 

C open  file  logical  unit  number  to 

C file  name  filnam 

C access  privileges  read  only 

CALL  0PENW(10,  FILNAM, 1 ,M) 
IF(M-1)90, 10,90 

C read  record  number  1 

10  CALL  RDRW (10,1 , I VAL ,10, M) 

I F (M- 1 )90,20,90 
20  CONTINUE 

C continue  processing  data 

C chanqe  access  privileges  to 
C exclusive  all 

C and  update  record  number  8 

30  CALL  M0DAPW(10,4,M) 

I F ( M-l  ) 30 ,40 ,30 

40  CALL  WRTRW(1 0,8,JVAL  ,1 0,M) 

IF(M-1 )90,50,90 
50  CALL  CL0SEW(10,M) 

STOP 

C error  handling  routines 
90  CONTINUE 


C example  program  XYZ 

INTEGER  FILNAM 
DIMENSION  KVAL(10) 

C open  file  logical  unit  number  7 
C file  name  filnam 

C access  privileges  exclusive  all 

10  CALL  0PENW(7, FILNAM, 4, M) 

I F (M-l  )10,20 ,10 

C read  record  8 and  update  contents 

20  CALL  RDRW(17,8,KVAL ,10,M) 

IF(M-1 )90 ,30 ,90 
30  CONTINUE 

C continue  processing  data 

C write  the  updated  record 

CALL  WRTRW(7,8,KVAL ,10,M) 

IFCM-1 )90,40,90 

40  CALL  CLOSEW ( 7 ,M ) 

STOP 

C error  handling  routine 
90  CONTINUE 


i 
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Relationship  of  Standard  to  the  Draft  Revised 
FORTRAN  dpX3J3/197fi 


C.l  Revised  FORTRAN  Standard 

j!  The  ANSI  X3J3  committee  has  been  considering 

revisions  to  standard  FORTRAN  (ISO  R1S39-1972) 
and  has  released  a draft  proposed  standard, 

X3J3dpANS  FORTRAN,  for  comments  and  review. 

| The  changes,  clarifications,  deletions  and 

additions  made  to  R1 539-1972  uo  not  invalidate 
any  portion  of  this  standard.  The  revised 
f FORTRAN  consists  of  a full  language  and  a 

sulset.  and  it  is  recommended  that  any  supplier 
providing  the  language  in  the  proposed  revision 
should  follow  tile  procedures  given  in  the  next 
| section.  These  recommendations  could  be 

invalidated  if  significant  changes  are  made  to 
the  present  draft  dpX3J3/197b  before  a new 
FORTRAN  standard  is  approved. 

C.2  Full  FORTRAN  dpX3J3/1976 

The  standard  is  compatible  with  this  FORTRAN. 

However,  Section  3 of  this  standard  - read/write 
to  direct  access  media  - is  covered  in  more  detail 
with  more  features  in  the  input/output  section  of 
dpX3J  3/ 1976 . 

C2.1  Extensions  to  Full  FORTRAN  dpX3J 3/ 1 976 

Section  2 of  this  standard  can  be  implemented  by 
an  extension  to  the  INQUIRE  feature  of 

cipX3J 3/1976.  The  recommended  method  for  1 

such  an  extension  is  to  use  two  (2)  more  key- 
words . 

LRVAL  = n where  n is  an  integer  expression 
Identical  to  the  argument  "m"  in 
Section  2. 

j 

PRIVLFDGE  = n where  n is  an  integer  expression  j 

identical  to  the  argument  "k"  in 
Section  2. 

The  actions  performed  by  execution  of  a reference  1 

to  the  subroutines,  OPENW  and  MODAPW,  are 
provided  by  the  INQUIRE  with  suitable  key 
words . 

C. 3 Subset  of  FORTRAN  dpX3J3/l 976 

This  standard  is  compatible  with  the  proposed 

standard  subset  of  FORTRAN  dpX3 J 3/ 1976.  However  I 

Section  3 of  this  standard  read/write  to  direct 
access  media  - is  covered  by  the  READ/WRITE  of 

FORTRAN  dpX3J3/1976.  I 
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SECTION  III 

WORKING  DOCUMENTS  OF  THE  INDUSTRIAL 
REAL-TIME  FORTRAN  COMMITTEE  CONCERNING 
WORK  ON  PROPOSED  ISA  STANDARD  S61.3, 
INDUSTRIAL  COMPUTER  SYSTEM  FORTRAN 
PROCEDURES  FOR  MANAGEMENT  OF  PARALLEL 
ACTIVITIES 


This  Section  presents  two  of  the  many  working  papers 
developed  by  the  Industrial  Real-Time  FORTRAN  Committee  in 
studying  all  aspects  of  the  subject  of  tasking  or  the  manage- 
ment of  parallel  activities.  A draft  standard  for  this  area 
is  now  under  development  by  the  Committee.  Mr.  Caro's  paper 
appeared  in  the  Minutes  of  the  1976  Spring  Regional  Meetings 
as  Appendix  A IV  D,  pp.  51-65,  Part  II , Technical  Appendices 
and  Tutorials . An  earlier  version  of  Professor  Petersen's 
paper  appeared  in  the  same  Minutes,  Appendix  A-III  D,  pp. 
273-311,  Part  I,  Narrative  and  Technical  Appendices . 
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FORTRAN  REQUIREMENTS 
FOR  THE  SEQUENCING  AND 
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"TASKING"  DEFINITIONS 
EXECUTABLE  PROGRAM 

Main  Program  + Subroutines;  Ref.  FORTREV  2.4.2 
X3J3/71 

PARALLEL  ACTIVITY  (PA) 

Time  parallel  activity  associated  with  a PCE 

PARALLEL  CODE  ELEMENT  (PCE) 

An  Executable  Program  which  is  associated  with 
a PA 

RELATED  ACTIVITIES  (RA) 


A SET  OF  RELATED  PA's 


-J/- 
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FORTRAN  PROCEDURES 

SCHEDULING 

TRNON  BEGIN  EXECUTION  OF  A PA  AT  A SPECIFIED  TIME  OF 
DAY 

START  BEGIN  EXECUTION  OF  A PA  FOLLOWING  A SPECIFIED 
TIME  INTERVAL 

CYCLE  INITIATE  THE  SERIES  OF  EXECUTIONS  OF  A PA 

FOLLOWING  A SPECIFIED  TIME  INTERVAL  AND  REPEAT- 
ING AT  A SECOND  SPECIFIED  INTERVAL 

CANCL  DESCHEDULE  A PA  IF  IT  HAS  PREVIOUSLY  BEEN 
SCHEDULED  AND  REMOVE  ANY  CYCLIC  REQUESTS 


FORTRAN  PROCEDURES  (CONT'D) 

SEQUENCING 

WAIT 

PA  EXECUTION  IS  SUSPENDED  UNTIL  THE  SPECIFIED 
TIME  INTERVAL  HAS  ELAPSED 

HOLD 

PA  EXECUTION  IS  SUSPENDED  UNTIL  "RELEASED"  BY 
ANOTHER  PA 

SYNC 

PA  REQUESTS  PRIVELEGE  TO  ENTER  A CRITICAL 
REGION 

DSYNC 

PA  INDICATES  END  OF  CRITICAL  REGION 

WAITE 

PA  EXECUTION  IS  SUSPENDED  UNTIL  THE  SPECIFIED  ! 

EVENT  HAS  OCCURED  1 

STOP 

PA  IS  TERMINATED  IMMEDIATELY 

L 
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FORTRAN  PROCEDURES  (CONT'D) 

RELATED  ACTIVITY  CONTROL 

RELESE  THE  SPECIFIED  PA  WILL  BE  ALLOWED  TO  CONTINUE  IF 
IT  HAD  BEEN  IN  A "HOLD"  CONDITION 

CON  THE  SPECIFIED  PA  WILL  BE  EXECUTED  IF  THE  SPECIFIED 
EVENT  OCCURS 

DCON  THE  SPECIFIED  PA  WILL  BE  DISASSOCIATED  WITH  THE 
SPECIFIED  EVENT 

ABORT  THE  SPECIFIED  PA  WILL  BE  TERMINATED  AT  THE  NEXT 
AVAILABLE  OPPORTUNITY 


L 


SYNTAX 

CALL  [START]  (i,  j,  k,  m) 

WHERE: 

i PA  NAME  (CHARACTER) 

j THE  TIME  DELAY  (INTEGER) 

k UNITS  OF  TIME  DELAY  (INTEGER) 

.EQ.  0 COUNTS  OF  SYSTEM  CLOCK 

,EQ.  1 MILLISECONDS 

.EQ,  2 SECONDS 

.EG.  3 MINUTES 

.EQ.  A HOURS 

M ERROR  INDICATOR  (INTEGER) 

(VALUE  DEFINED  ON  COMPLETION  OF  STATEMENT] 

.LE.  0 UNDEFINED 

.EQ.  1 REQUEST  ACCEPTED 

.GE.  2 REQUEST  REJECTED 

(2  ~*N  MAY  INDICATE  REASON) 


1 
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TASKING  FUNCTIONAL  REQUIREMENTS 

□ INITIATION  j 

CAUSE  PROGRAM  TO  BEGIN  I 

□ TERMINATION 

CAUSE  A PROGRAM  TO  CEASE  EXECUTION 

□ SYNCHRONIZATION 

ALLOW  PROGRAMS  WHICH  SHARE  RESOURCES  TO  TIME-PHASE 
COORDINATE  EXECUTION 

□ COMMUNICATION 

PASS  DATA  BETWEEN  PROGRAMS 

□ EXCEPTION  HANDLING  j 

ALLOW  USER  TO  SPECIFY  SYSTEM  RESPONSE  TO  DEFINABLE  < 

ERRORS 
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INITIATION 


PROGRAM  NAME 

STARTING  TIME 

OFF-SET  FROM  CURRENT  TIME 

REPETITION  TIME 

NUMBER  OF  REPETITIONS 

OVERRUN  ERROR  ACTION 

PRIORITY 

AUTHORITY 

PARAMETER  LIST 


ERROR  ACTION  IF  ALREADY  INITIATED 
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TERMINATION 

□ SELF  (PROGRAM  ITSELF  DECIDES) 

- STOP  NOW 

- STOP  DUE  TO  ERROR 

□ OTHER  (CAUSE  ANOTHER  PROGRAM  TO  TERMINATE) 

- NORMAL,  AT  CLEAN/SAFE  OPPORTUNITY 

- EMERGENCY,  GET  OUT  NOW 

□ SERIES/SET  (CAUSE  A SET  OF  RELATED  PROGRAMS  TO  ALL 
TERMINATE) 

- NORMAL 

- EMERGENCY 

□ GENERIC  (CAUSE  ALL  SCHEDULED  EXECUTIONS  OF  A SPECIFIC 
PROGRAM  TO  TERMINATE) 

- NORMAL 

- EMERGENCY 
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SYNCHRONIZATION 


□ WITH  EVENT 

- WAIT  FOR  EVENT 

•HARDWARE  (CONTACT,  INTERRUPT) 
•SOFTWARE  (SEMAPHORE,  FLAG,  COMMON) 

□ WITH  TIME 

□ RESOURCE  - CRITICAL  REGION 

□ WITH  ANOTHER  PROGRAM 

- HOLD/RELEASE 


□ USE  OF  SHARED  VARIABLE  NAMES  AND  PROGRAM  NAMES 


COMMUNICATIONS 


SEND 

- PROGRAM  NAME  (DESTINATION) 

- DATA  IDENTIFIER 

- DATA  VALUE 

- DATA  ROUTING 

- WHEN  (START  TIME/OFFSET) 

- ON  EVENT 

- AUTHORITY 

- ERROR  RESPONSE 

RECEIVE 

- DATA  IDENTIFIER 

- DATA  VALUE 

- AUTHORITY 

- ERROR  RESPONSE 

- ORIGIN  PROGRAM  NAME 

- ACTUAL  ROUTE 


i 


r 

i 


r' 
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EXCF.PTION  HANDLING 

□ EXECUTION  ERROR  \ 

- OVER/UNDER  FLOW 

- QUEUE  FULL  | 

- FORMAT  MISSMATCH 

□ OVERRUN  ON  SCHEDULE 

□ LACK  0^  RESOURCES 

□ FAILURE  OF  RESOURCES  ! 

□ PREDICTABLE  DELAY 

- DEVICE  NOT  READY 

- LINK  BUSY 
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GENERIC  FORM  OF  CALL 


CALL  INITIATE  (PROGRAM  NAME  (PRIORITY  = PRIORITY  VALUE] 
(AUTHORITY  = AUTHORITY  KEY] 

[EVENT  = EVENT  MARK, 


"(J'TIME  = TIME  OF  DAY 
V DELAY  = TIME  INTERVAL 

[now 


CYCLE  = CYCLE  INTERVAL, 

rFOR  = TIME  PERIOD 
3 UNTIL  = TIME  OF  DAY 
C. FOREVER 


i 


LIST  = PARAMETER  LIST  NAME 
CYCLE  NAME  = CYCLE  NAME] 
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This  document  represents  a step  of  a continuous  updating  of  working  material 
within  International  Purdue  Workshop  on  Industrial  Computer  Systems,  Technical 
Committees  on  Real-Time  FORTRAN.  Primarily,  it  is  written  to  express  my  own 
viewpoints,  resulting  from  some  years' work  within  the  FORTRAN  committees: 

First,  with  the  American  Committee^  and  more  recently  as  a member  of  the  European 
TCI  (Technical  Committee  on  Real-Time  FORTRAN) . 

The  previous  document  in  the  series,  ref.  [18],  has  been  distributed 
witnin  the  American  as  well  as  the  European  Committee  on  Real-Time  FORTRAN. 

With  some  minor  suggestions  to  improvements,  the  document  was  approved  by  the 
European  Committee,  at  the  committee  meeting  in  Brussels,  in  the  beginning  of 
September,  1976.  The  present  document  represents  a quick  rewriting  of  [18], 
with  an  effort  to  incorporate  the  ideas  and  improvements  suggested  at  the 
Brussels  meeting.  The  document  has  been  prepared  before  the  Fourth  Internatio- 
nal Meeting  of  the  International  Purdue  Workshop  on  Industrial  Computer  Systems, 
which  will  be  held  on  November  8.  - 11.,  1976.  The  short  time  has  prevented 
a new  discussion  of  the  contents,  within  the  European  TCI.  Since  the  predecessor 
of  this  document  was  largely  accepted  by  TCI  with  only  minor  requests  for  changes, 
however,  the  present  document  may  be  considered  to  express  largely  the  view- 
points of  the  European  Committee  on  Real-Time  FORTRAN  within  "Purdue  Europe". 

It  feels  appropriate  to  remind  about  the  short  range  goal  for  the  FORTRAN 
commi ttcework . As  in  previous  documents,  I consider  it  urgent  to  emphasize  that 
the  work  on  standardization  of  Real-Time  mechanisms  should  be  concluded  at  an 
early  date.  It  is  very  important  to  keep  as  close  to  the  current  Standard 
FORTRAN  as  possible,  however.  Deviations  should  only  be  accepted  in  those  cases 
where  basic  principles  inherent  with  concurrent  operation  of  real-time  programs 
ir  not  covered  by  the  the  current  ANSI  standard.  Consequently,  we  encounter 
now  a new  situation,  with  the  recent  release  by  ANSI's  X3J3  committee  of  their 
now  "draft  proposed  ANS  FORTRAN,  X3J3/76".  Although  not  finally  approved  as 
the  new  FORTRAN  standard,  one  must  expect  the  new  standard  to  be  quite  close  to 
tl.'  present  draft.  This  will  influence  our  work  on  real-time  mechanisms  for 
FORTRAN  quite  considerably.  Time  has  not  permitted  the  author  of  the  present 
doc  iment  to  fully  incorporate  all  ohvi  ous  modifications  caused  by  the  new 
standard.  It  i also  considered  a subject  for  future  committee  work  to  consider 
all  consequences  of  the  new  standard.  Consequently,  the  reader  might  find 
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portions  of  the  present  document  obviously  written  at  an  early  stage  while 
other  portions  are  of  more  recent  date,  influenced  by  recent  committee  dis- 
cussions as  well  as  the  draft  proposed  FORTRAN.  I hope  that  the  reader  will 
understand  the  reasons  for  this  lack  of  homogeneity  and  that  the  main  principles 
and  ideas  will  be  evident,  despite  some  inhomogeneities  in  the  forms  of  the 
document. 

During  the  spring  of  1975,  the  US  FORTRAN  committee  achieved  some  signifi- 
cant results  in  the  handling  of  Parallel  Activities,  formerly  termed  "tasking". 
Valuable  contributions  are  also  made  by  members  of  the  European  TCI.  The 
great  number  of  valuable  contributions  during  discussions  has  not  been  matched 
by  written  papers  as  documentation  of  the  orally  achieved  results,  however,  at 
least  within  the  framework  of  Purdue  Workshop.  Like  [18],  the  present  paper 
represents  an  attempt  to  satisfy  some  of  these  needs.  Additionally,  the  present- 
document  benefits  from  a somewhat  higher  degree  of  approvement  from  the 
European  TCI  than  [18]  does.  Consequently,  I will  suggest,  that  the  present 
document  : s considered  as  a basis  for  further  committee  work  and  that  the 
consequences  of  the  draft  proposed  ANS  FORTRAN  will  be  discussed,  so  that  its 
inlluence  on  the  real-time  mechanisms  can  be  revealed  and  eventually  incorporated 
i ri  a Standard  puprr  on  Real-Time  FORTRAN,  hopefully  attainable  in  a near 
f u t ure . 
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2.  DEFINITIONS  OF  IMPORTANT  TERMS 


Throughout  the  present  paper,  the  following  terms  and  their  definitions 
ap  used.  Some  of  the  definitions  correspond  largely  to  those  formulated 
at  the  committe  meeting  during  the  second  American  Regional  Meeting  of 
Purdue  Workshop  in  April  1975.  To  some  extent,  the  definitions  are  inspired 
by  l 4]. 


The  terms  are  written  in  capital  letters  in  their  definitions.  Terms 
defined  elsewhere  in  this  vocabulary  are  underlined.  It  will,  however,  be 
underlined  only  at  the  first  occurrence  within  the  same  definition  paragraph. 


OPERATION. 


COMPUTATION . 


ACTIVITY. 


A deterministic  rule  for  the  generation  of  a finite 
set  of  data  from  another  finite  set  of  data. 

A finite  set  of  operations  applied  on  a finite  set  of 
data,  in  an  attempt  to  solve  a problem.  If  the  compu- 
tation really  solves  the  problem,  it  will  also  be  an 
ALGORITHM. 

A computation,  where  the  operations  are  performed  in 
a strict  sequential  order. 


PARALLEL  ACTIVITIES.  A set  of  activities  whose  operations  may  overlap  in  time. 

Parallel  activities  are  DISJOINT  if  every  one  of  them 
only  refers  PRIVATE  DATA,  i.e.  data  that  are  not  accessed 
by  any  other  activity  of  the  set.  They  are  INTERACTING 
if  they  refer  to  SHARED  DATA,  i.e.  data  that  are  accessed 
by  more  than  one  activity  of  the  set. 

PROGRAM.  A description  of  a computation,  expressed  in  a formal 

language,  PROGRAMMING  LANGUAGE. 

SEQUENTIAL  PROGRAM.  A program  consisting  of  operations  that  can  only  be 

performed  strictly  one  at  a time  without  any  overlap 
in  time.  See  definition  of  "Activity".  An  Activity 
is  described  by  one  or  more  sequential  programs  excluding 
each  other  in  time. 


PrlYS  ICAI  PROCESSOR. 


A physical  component  capable  of  executing  an  activity 
defined  by  a stored  program. 


VIRTUAL  PROCESSOR. 


MULTIPROGRAMMING. 


SYNCHRONIZATION. 


CRITICAL  REGION. 


SEMAPHORE. 


MONITOR. 


MESSAGE  BUFFER. 


-54- 

A simulated  component,  capable  of  executing  an  activity 
defined  by  a stored  program.  The  virtual  processor 
may  be  realized  by  a physical  processor  or  simulated 
by  program  execution. 

Programming  techniques  or  organizational  forms  which 
make  use  of,  or  allow,  parallel  activities. 

A general  term  for  restrictions  regarding  the  order  in 
which  operations  are  performed.  E.g.  a synchronization 
rule  may  specify  the  order,  priority  or  mutual  exclusion 
in  time  between  two  or  more  operations. 

Specifically,  the  term  synchronization  will  here  be  tied  to 
parallel  activities.  According  to  the  definition  above, 
only  interacting  parallel  activities  are  relevant  to 
consider  for  synchronization. 

A part  of  a sequential  program  operating  on  shared  data 
such  that  this  program  part  must  have  exclusive  access 
to  the  shared  data  during  the  execution. 

A structure  of  shared  data , used  for  the  exchange  of 
synchronizing  signals  between  interacting  parallel 
activities.  Operations  on  a semaphore  must  only  be  per- 
formed within  a critical  region . 

A structure  of  shared  data  and  a set  of  operations  on 
this  structure,  for  the  purpose  of  synchronization  of 
interacting  parallel  activities.  The  shared  data  can 
only  be  accessed  through  appropriate  activations  of  the 
set  of  operations  contained  in  the  monitor.  In  this 
respect,  the  data  are  local  to  these  operations,  while 
the  operations  are  shared.  The  operations  can  only  be 
activated  by  one  of  the  controlling  parallel  activities 
at  a time. 

A structure  of  shared  data , used  for  exchange  of  data 


between  parai lei  activities  . 
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OPERATING  SYSTEM.  An  organized  collection  of  system  programs  acting  as  an 

interface  between  computer  hardware  and  users,  providing 
users  with  a set  of  facilities  to  simplify  the  design, 
coding,  program  error  discovery,  and  maintenance  of 
programs,  as  well  as  controlling  the  allocation  of 
resources  to  assure  efficient  operation  [ 1 4 ] . See  execu- 
tive system. 

EXECUTIVE  SYSTEM.  The  part  of  an  operating  system  controlling  the  allocation 

of  resources  in  a computing  system.  One  major  resource 
is  processor  execution  time*. 

SUSPENDED.  One  of  the  definite  states  of  an  activity. A suspended  ac- 

tivity has  stopped  the  execution  of  its  virtual  processor, 
and  is  waiting  for  a specified  event  to  continue  the 
execution  of  its  virtual  processor. 


CONDITIONAL  CRITICAL  REGION.  A program  structure  providing  synchronization  mecha- 
nisms between  interacting  parallel  activities.  A conditio- 
nal critical  region  is  a critical  region  realized  as  a 
call  to  the  executive  system,  comprising  specifications 
of  conditions  for  the  calling  program's  entrance  into 
the  critical  region.  If  such  entrance  permission  is  not 
granted  immediately,  the  calling  program  will  be  sus- 
pended. 


*)  The  author  is  aware  of  the  flourishing  number  of  diverging  definitions 
within  this  subject.  Frequently,  operating  system  is  used  where  this 
paper  uses  executive  system.  The  determinant  reason  for  the  choice  in  this 
paper  is  an  effort  to  find  a term  less  biased  with  fixed  but  differing 
interpretations.  Since  operating  systems  often  include  system  programs  pro- 
viding other  facilities  (like  those  listed  above),  there  is  a need  for  a 
term  with  a more  restricted  scope,  and  also  for  one  that  is  less  tied  to 
specific  but  somtimes  conflicting  meanings. 
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event.  A significant  discrete  occurrence  or  incident  which  is 

intended  to  affect  some  program  execution  in  a planned 
manner.  The  source  of  an  event  can  belong  logically 
to  an  entity  distinctively  apart  from  the  affected  pro- 
gram unit  or  units.  An  event  itself  occurs  instantane- 
ously and  is  of  infinitesimal  duration.  The  fact  that 
an  event  has  occurred  is  indicated  by  an  EVENTMARK  which 
is  a binary-valued  program  variable  of  type  Boolean. 

It  is  worth  noting,  that  the  term  "Parallel  Code  Element",  suggested  at  the 
Workshop  at  Purdue  April  '75,  should  be  completely  superfluous.  "Code"  is 
covered  by  "program",  and  "parallel"  should  pertain  to  "activity"  rather  than 
the  programmed  realization  of  it. 

Please  also  remark,  that  I have  found  it  logical  and  linguistic  correct 
to  use  the  term  "activity"  where  the  committee  discussion  ended  up  with 
"parallel  activity".  It  is  "parallel"  only  when  "parallelled"  with  some 
other  activity.  Logically,  one  could  have  chosen  "parallelable" , indicating 
that  the  activity  might  be  activated  in  parallel  with  some  other,  similar 
activity.  The  last  term  seems  rather  cumbersome  and  artificial, however , and  I 
see  no  real  need  for  the  emphasis  of  the  "parallellable"  quality,  since 
"Parallel  Activities"  are  defined  specifically. 

Obviously,  there  is  a need  for  a term  covering  several  activities  perform- 
ing in  parallel,  and  now  the  term  "parallel  activity"  fits  very  well.  At 
the  committee  meetings,  the  term  "set  of  parallel  activities"  was  proposed; 
this  will  now  appear  unnecessary  complicated  in  comparison. 


L. 
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_3  ■ MATHEMATICAL  MODELS  FOR  PARALLEL  ACT IV I TIES 

The  clarity  and  distinction  in  the  description  of  an  activity's  various 
states  and  transfer  between  states,  is  greatly  enhanced  through  the  use  of 
"state  diagram”  and  state  transitions  between  states.  This  idea  was  recognized 
early,  and  several  different  state  diagrams  have,  through  the  years,  been 
proposed  in  the  discussion  within  the  Workshop.  The  state  diagram,  with  dis- 
tinct states  and  transitions  between  states  is, in  fact,  not  only  a practical 
descriptive  method  for  clarification,  but  it  yields  a mathematical  model  of 
the  system,  with  close  relation  to  automata  theory. 

Theoretically,  any  discrete,  simple  sequential  machine  can  be  represented 
by  a model,  which  can  be  of  form  of  a so  called  Mealy  or  a Moore  model,  which 

are  theoretically  equivalent.  Both  models  are  characterized  by  a finite  set 

of  distinct  states  and  a finite  set  of  transitions  between  the  states. 

Given  any  initial  state,  an"input"  may  cause  a transition  to  another  state. 
Comparing  different  initial  states,  the  same  "input"  may  cause  transitions  to 
different  states,  but  for  any  initial  state,  the  transition  for  a given  input 

is  non-ambiguous . Ir.  a Mealy  model,  output  functions  are  linked  to  the  trans- 

ition:., and  in  a Moore  model,  the  output  functions  are  associated  with  the 
states.  For  the  discussion  of  our  topic,  the  Moore  type  appears  the  most 
suitable,  and  "output"  may  be  interpreted  as  "actions"  in  the  state,  for 
example  program  execution.  The  Moore  and  Mealy  models  are  defined  for  single 
sequential  processes,  i.e.  the  process  (activity)  is  in  one  and  only  one  state 
at  any  instant  of  time.  The  concept  is,  however,  very  easily  extended  to  a 
multiple  of  separate  activities: 

Such  a system  can  simply  be  considered  as  modelled  by  a number  of  disjoint 
but  similar  diagrams.  It  seems  feasible  to  apply  a three-dimentional  picture, 
with  the  similar  individual  diagrams  sandwitched  on  top  of  each  other  and  orient- 
ed so  that  the  identical  states  of  the  individual  diagrams  cover  each  other. 

The  total  system  will  have  a number  of  state  "stacks",  the  same  number  as 
the  number  of  states  in  each  diagram.  Each 'fe tack"  represents  the  particular 
state  of  all  activities,  and  it  is  easy  to  impose  certain  restrictions  to  the 
maximum  number  of  activities  entering  the  same  state:  In  the  composite  model, 

his  will  be  the  maximum  number  of  "entered"  wafers  in  the  stack.  For  the 
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system,  the  limitations  are  dictated  by  available  resources,  which,  for 
example,  can  be  table  space. 

In  designing  a suitable  state  model,  several  possibilities  will  generally 
exist,  and  several  of  these  can  seem  equally  advantageous.  All  feasible  models 
should,  however,  exhibit  the  following  features,  corresponding  to  requirements 
for  the  system: 

1.  The  transitions  roust  be  non-ambiguous  (as  discussed  above). 

2.  The  transitions  are  carried  out  instantly,  i.e.  in  zero  time. 

3.  The  model  should  not  contain  terminal  states. 

4.  The  model  should  be  a Markov  system,  i.e.  transitions  from  a 
state  should  depend  only  upon  the  state  and  current  conditions, 
not  on  the  previous  state  and  the  transitions  that  brought  the 
activity  into  the  present  state. 

5.  An  activity  should  exist  in  one  state  only  at  a time. 

A terminal  state  is  a state  with  transitions  only  originating  in  the  state 
and  none  conducting  into  it,  or  transitions  only  conducting  into  the  state 
and  none  going  out  from  it.  The  reason  for  this  requirement  is  obvious:  It 

requires  transitions,  outside  the  model  to  bring  an  activity  to  or  from  such 
a state. 


4_;  DESIGN  OF  A SUITABLE  MODEL 

It  is  not  immediately  evident,  that  the  set  of  models,  feasible  from  a user's 
point  of  view,  is  the  same  as  the  set  of  feasible  models  as  seen  from  the  oper- 
ating system.  The  sets  will  probably  overlap,  however,  indicating  that  it 
should  be  possible  to  fj.nd  a model,  suitable  from  both  viewpoints. 

I f we  set  the  goal  to  find  an  optimal  model,  however,  it  becomes  less  likely 
that  a model.  Satisfactory  from  both  viewpoints, can  be  found. 

During  the  years,  several  models  have  been  proposed,  evidently  attempting 
to  satisfy  diverging  requirements  from  the  user's  and  the  operating  systems 's 
needs.  It  is  probably  safe  to  say,  that  compromises  have  been  necessary  and 
thus  the  model  has  never  been  optimal,  from  either  viewpoint.  Let  mo  , shortly, 
explain  certain  controversial  requirements: 


oy- 


* The  operating  system  is  concerned  with  assigning  processor  to  an 
activity,  ready  to  execute.  Usually,  there  are  more  activities 
than  available  processors;  thus  some  timesharing  must  be  performed. 

A model  must  satisfy  this  and  must  contain  states  like  RUNNING,  RUNN- 
ABLE etc.  The  user,  on  the  other  hand,  basically  doesn't  want  to 
bother  with  these  problems,  on  which  he  does  not  have  any  influence 
anyway.  His  requirement  is  just  to  get  his  activity  executed  within 
a tolerable  time  limit. 

As  seen  from  the  operating  system,  memory  and  other  resources  must  be 
made  available  before  an  activity  can  execute.  On  the  other  hand, 
in  order  to  economize  the  use  of  limited  amount  of  resources,  these 
may  frequently  be  shared.  For  example  is  it  sometimes  necessary  to 
release  some  memory  space  from  a preempted  program  (core  swapping) . 
The  order,  in  which  resources  should  be  made  available  to  competing 
activities  may  be  the  object  of  considerable  evaluation,  compromises 
and  complex  solutions.  It  is  not  very  likely  that  a user  wants  to, 
or  should  be  allowed  to,  bother  with  these  detailed  problems,  belong- 
ing to  the  operating  system's  area  of  responsibility. 

The  model  proposed  in  the  following  is  intended  to  satisfy  the  requirements 
sketched  above  and  in  tne  previous  paragraph,  optimized  from  the  user's  view- 
point. It  is  illustrated  by  the  transition  diagram  of  Figure  1 and  conforms 
to  the  model,  unanimously  attained  during  the  FORTRAN  committee  meeting  in 
Phoenix,  January  1975. 

The  following  conventions  are  used  for  the  drawing  and  symbols,  adopted 
from  [5]  and  also  used  in  my  preceding  paper  [l]: 

State  transitions  are  effected  by  subroutines  and  procedures  identified 
by  standardized  names,  by  executive  operations  and  by  various  events.  These 
categories  are  differentiated  between  in  the  diagram: 

* Capital  letters  in  box:  Effect  on  an  activity  imposed  by  another 
activity.  I.e.  a subroutine  call  in  one  activity  has  the  indicated 
effect  on  anotaer  activity. 

* Capital  letters  without  box:  Effect  imposed  by  the  activity  itself. 

* 


Small  letters:  Executive  operations  performed  by  the  monitor, 

possibly  triggered  by  an  event. 
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The  transitions  are  largely  identical  with  those  of  [lJ.  I have  found  it 
valuable  to  adopt  from  [5]  another  transition  for  cyclic  operation:  TCYCLE. 
Further,  there  are  some  changes  in  synchronizing  transitions.  These  changes 
will  be  explained  in  later  paragraphs. 


4.1.  Multiple  calls  for  state  transitions. 

One  must  accept  that  several  different  programs  (activities)  may  issue  con- 
flicting transition  calls  regarding  one  and  the  same  activity.  Thus,  it  be- 
comes necessary  to  clarify  the  situations  that  may  arise,  analyze  the  possible 
precautions,  and  to  decide  how  these  problems  should  be  resolved. 

Let  us, firstly,  mention  two  typical  cases  which  occur  commonly: 

a.  An  activity  may  be  scheduled  by  TRNON  or  START  for  execution  at 
some  future  time,  but  also  connected  to  several  other  events,  for  instance 
by  call  of  CON. One  of  these  could, for  example,  be  the  activation  of  a 
button  on  the  operator's  console,  signalling  the  activity  to  execute. 

b.  A running  activity  may  want  (need)  to  schedule  itself,  by  call  of 
START,  TRNON  or  CON. 

Rule  no.  5 of  para.  3 denies  an  activity  to  be  in  more  than  one  state  at  a 
time.  This  rule  seems  to  be  agreed  upon  as  necessary,  by  all  committee 
members,  besides  it  is  a fundamental  condition  for  keeping  the  model  in 
accordance  with  theoretical  models  of  automata  theory.  Let  us,  therefore, 
try  to  explore  all  possible,  as  well  as  impossible,  solution  methods: 

1.  Rule  5 is  abandoned,  thus  permitting  the  activity  to  be  in  more  than 
one  state  at  a time. 

This  is  not  acceptable,  from  arguments  above  and  several  others, 
expressed  by  other  committee  members  during  discussions. 

2.  Reject  any  further  calls  for  activation  of  an  activity;  i.e.  reject 
calls  that  conflict  with  the  present  state. 

Discussion  of  consequences: 

It  is  indeterminate  which  of  several  activating  activities  that  wins 
the  race  of  acquiring  the  object  activity  the  first  time.  Thus,  the 
losing  activities  must  be  informed  correspondingly,  to  enable  them  to 
repeat  the  call  until  success.  This  repeated  calling  must  be  fiogrammed, 
in  the  user's  program,  and  involves  very  much  overhead,  unnecessary 
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because  it  is  inherently  linked  to  this  method,  as  opposed  to  the  method 
discussed  in  section  3 below. 

Another  deficiency  of  this  method  is  that  the  inclusion  of  the  program 
statements  for  the  repeated  calls,  in  the  application  program,  represents 
an  extra  workload  on  the  application  programmer. 

The  method  makes  the  operating  system  implementation  somewhat  simpler, 
though.  The  author  is,  however,  not  inclined  to  emphasize  the  importance 
of  simple  implementation  of  operating  systems,  at  the  expence  of  run- 
time overhead  as  well  as  convenience  and  safety  of  application  program- 
ming . 

3.  Call  to  the  executive  system  (by  calls  of  START,  TRNON  or  CON)  for  state 
transition  to  PENDINGcauses  listing  in  a table, appropriately  called  "pending- 
table".  Each  activity  may  have  a maximum  of  one  entry  in  this  table, 

but  complex  conditions  should  be  allowed:  Limited  only  by  some  maxi- 

mum table  size,  all  valid  subroutine  calls,  intended  to  cause  state 
transition  to  PENDING  should  have  its  "running-condition"  OR-ed  to 
the  event-function  constituting  the  condition  for  the  subsequent  state 
transfer  to  RUNNING.  This  rule,  besides  being  quite  obvious,  has  a 
further  advantage:  It  gives  a very  simple  and  logical  operation  of 

the  CYCLE,  TCYCLE,  and  CON  calls,  i.e.  the  calls  causing  possibility  of 
multiple  subsequent  activations  (RUNs) : Whenever  an  activity  attains 

state  DORMANT,  (by  execution  of  EXIT) , the  pending-table  is  checked. 

If  listed,  the  activity  will  be  transferred  immediately  to  state 
PENDING,  guided  by  an  OR-function  of  run-conditions  from  the  table- 
entry.  If  the  listing  call  was  one  of  the  recurrence  calls  CYCLE, 

TCYCLE  or  CON,  the  table  entry  will  remain.  The  same  will  be  the  case, 
if  multiple  colls  of  START  or  TRNON  were  made , leaving  the  future  acti- 
vation times  in  the  table.  Thus,  there  will  be  no  difference,  in 
principle,  between  the  immediate  effects  of  multiple  calls  of  START 
or  TRNON  and  the  recurrence  calls  CYCLE,  TCYCLE,  and  CON.  The  effect 
of  the  recurrence  calls  will  only  be,  that  the  remaining  conditions  in 
the  table  entry  will  be  adjusted  recursively,  at  the  instant  when  the 
activity  is  transferred  past  DORMANT  to  PENDING  after  an  EXIT. 

4.  (Applicable  if  the  standard  and  the  implementation  allow  entirely  new 
activities  to  be  created  dynamically:) 

Any  new  activation  causes  the  creation  of  a new  activity,  similar  or 
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equi valent  (or  even  identical)  to  the  previous  one.  The  newly  created 
activity  must  get  its  own  resources,  share  of  resources,  or  require- 
ment for  common  resources.  This  includes  its  own  table  space  in 
the  primary  store  (core  store) . 

5.  A combination  of  methods  no.  3 and  4 above: 

Different  (parent)  activities  create  or  activate  different  identical 
child  activities.  Several  activations  of  the  same  named  activity 
from  the  same  parent  activity,  however,  refer  to  the  very  same  child 
activity,  such  that  these  succeeding  transition  calls  should  merely 
be  listed  (queued) . 

Prom  a standardization  point  of  view,  method  no.  5 looks  preferable: 

It  is  advantageous  because  of  its  generality;  it  is  a superset  of  methods 
3 and  4.  Thus,  it  is  convenient  in  the  standard  to  leave  it  to  tne 
particular  implementation,  to  what  extent  new  activities  may  be  created. 
This  method  also  simplifies  the  resolution  of  the  possible  ambiguity 
relating  to  which  activations  of  an  object  activity  that  shall  be 
eliminated  by  a call  of  DECYCLE , DECON  or  CANCL.  It  seems  reasonable 
to  let  these  calls,  from  a "parent"  activity,  affect  only  its  child 
activities,  i.e.  activities  created  by  the  same  activity. 

It  is  imperative  to  mention  a word  of  caution,  however,  against  an  impetuous 
acceptance  of  recursive  activity  creation  as  a permissible  feature  in  the 
standard.  Several  reputed  authors  have  warned  against  the  implementation  of 
this  feature  (see  for  example  [15],  [16]).  The  main  reason  is  the  considerable 
amount  of  added  complexity  of  the  operating  system  which  again  may  reduce  soft- 
ware reliability.  Related  to  this  question,  could  also  be  mentioned  several 
authors'  questioning  of  the  necessity  and  desirability  of  recursive  subroutine 
calls.  See  for  example  D.E.  Knuth's  well  known  and  rather  recent  article  [ 1 7 ] . 
Since  it  is  warned  against  recursive  functions  in  pure  sequential  programs, 
it  seems  even  more  important  to  be  sceptic,  dealing  with  real  time  concurrent 
programs . 

Another  strong  argument  for  rejection  of  recursrvity  is  the  fact  that  we 
are  talking  about  FORTRAN,  not  an  I,TPL.  Let  us  be  realistic  enough  to  acknowledge 
t.hc-  short-time  goal  of  getting  to  a conclusion  In  the  work  of  standardizing  Real- 
time FORTRAN.  I am  very  much  concerned , t hat  an  inclusion  f dynamic  and  recursive 
creation  of  activities  involves  the  danger  of  reducing  software  reliability  a' 


-63- 


welJ  as  stretching  the  date  of  a final  Standard  S61  far  out  in  the  future. 

Concluding,  I find  method  no. 3 above  to  be  the  best  among  those  discussed, for 
the  handling  of  multiple  calls  for  state  transitions. 


4.2.  Events. 


Crucial  to  the  description  of  the  model  is  the  term  EVENT,  defined  in 
paragraph  2.  Some  additional  explanations  may  be  appropriate: 

The  occurrence  may  be  external  or  internal:  The  effect  of  an  external 

event  will  be  transmitted  through  the  processor's  input  interface 
system  as  an  interrupt  request  signal  or  a signal  actively  read  by 
some  program  statements.  The  source  of  an  external  event  will 
generally  be  of  some  physical  nature. 

An  internal  event  is  characterized  by  some  condition  change  within 
a program  as  a consequence  of  some  program  action.  With  relation  to 
the  effect  of  an  event,  it  is  not  distinguished  between  external  or 
internal  nature  of  its  origin. 

As  evident  from  the  definition,  time  can  be  a basis  for  an  event.  A prevalent 
time  is  defined,  related  to  the  equation: 

B + t > tl  (1) 

where : 

t is  wall  clock  time 

tl  is  some  predetermined  point  of  time 

B is  the  oventmark,  recognized  as  a binary  boolean  variable. 
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4.3  Definition  of  states. 

As  illustrated  in  Figure  1,  the  model  has  5 states,  defined  by  the  committee 
as  follows: 

NON-EXISTENT 

A non-existent  activity  is  unknown  to  the  activity  manager. 

DORMANT 

A dormant  activity  is  known  to  the  activity  manager  and  is  not  in 
any  of  the  states  PENDING.running, or  SUSPENDED. 

PENDING 

A pending  activity  has  been  associated  with  an  event  such  that  when 
the  event  occurs,  the  activity  will  be  transferred  to  state  RUNNING. 

RUNNING 

A running  activity  is  executing  in  its  virtual  processor.  This 
means  that  its  program  will  be  executing  on  a real  processor  if  all 
necessary  resources  are  assigned  to  it.  Otherwise,  it  will  be  wait- 
ing for  its  required  resources. 

SUSPENDED 

A suspended  activity  has  stopped  the  execution  of  its  virtual  proces- 
sor, and  is  waiting  for  a specified  event  to  continue  the  execution 
of  its  virtual  processor. 
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5.  DEFINITION  OF  ABSOLUTE  TIME 

•] 

Time  must  be  defined  accurately  and  unambiguously , for  example  when  used  as 
parameters  for  TRNON  and  similar  subroutine  and  executive  calls.  As  explained 
in  [l],  ambiguity  results  from  modular  interpretation,  if  higher  order  component:, 
and  zero  reference  point  of  the  complete  time  description  are  omitted.  The  only 
remedy  is  to  include  all  these  components  (hour,  day,  month,  year,  reference 
time  zero,  eg.  AD) , either  explicitely  as  contents  in  table  elements,  or 
implicitely  as  generally  acknowledged  constants. 

Usually,  the  highest  order  components,  like  month  and  year,  as  well  as  the 
zero  reference,  are  implicitely  acknowledged.  This  works  usually  fine,  as 
long  as  all  references  refer  to  the  same  (current)  module.  Ambiguity  results 
on  the  boundary  between  modules,  however.  An  example  will  clarify: 

On  March  30.,  an  activation  call  for  a certain  activity  is  issued,  by 
CALL  TRNON.  Activation  time  is  specified  to  be  some  time  on  date  15.  Is  this 
to  be  interpreted  as  the  15th  of  next  month,  i.e.  April  15.,  or  are  we  just 
very  late  and  really  mean  March  15.?  If  so:  should  the  activity  be  activated 
immediately? 

The  only  safe  and  correct  remedy  is  to  include  all  time  components,  at 
least  in  principle.  This  does  not  mean  that  the  user  always  has  to  specify 
all  components.  All  components  should  be  included  in  a referred  array,  however, 
making  the  user  responsible  for  appropriate  modification  of  higher  order  compo- 
nents on  the  boundary  between  two  time  modules.  In  the  example  shown  above, 

"March"  was  probably  the  "old"  contents  of  the  month-element  of  the  time 
spesif ication  array.  It  should  be  the  user's  responsibility  to  change  this 
to  "April",  if  April  15.  is  the  expected  time  of  activation. 

This  makes  it  necessary,  wherever  absolute  time  is  specified,  to  provide 
for  table  space  for  all  components  of  the  complete  time  specification.  The 
only  elements  that  may  be  omitted  are  the  time  zero  and  whether  time  refers  to 
"local  time"  ("Normal"  or  possibly  "Daylight  savings  time")  or  UTC  (GMT)  . But 
the  omission  of  these  elements  must  indeed  presuppose  that  they  are  acknowledged 
implicitely. 
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The  order,  in  which  the  elements  are  arranged  in  the  tables,  should  indeed 
be  monotonic. I have  heard  considerable  arguing  for  a decreasing  order : hour-minutes- 
seconds  etc.  for  increasing  element  numbers.  In  [18],  I capitulated  for  these 
arguments  and  arranged  the  time  elements  in  a non-monotonic  order.  After  dis- 
cussions at  the  Brussel  meeting  in  Sept.  '76  of  the  European  TCI,  I have  re- 
arranged the  order  again,  back  to  my  earlier  proposals,  as  contained  in  [ 1 ] . 


All  technical  and  logical  reasons  favor  the  following  order: 
Index  1 Basic  time  unit 
" 2 second 

" 3 minute 

" 4 hour 

" 5 day 

" 6 month 

" 7 year 


People  arguing  against  this  order,  in  favor  of  reverse  order  of  index  1-4  only, 
are  herewith  invited  to  defend  their  position  with  convincing  references  to 
"already  standardized"  authoritative  sources.  I must  admit,  that  I have  been 
unable  to  recover  any  reference  to  such  sources.  *) 


6.  DEFINITION  OF  SUBROUTINE  AND  PROCEDURE  CALLS 


Ar.  activity  may  make  a state  transition,  by  virtue  of  a monitor  call  within 
the  activity's  own  program  or  another  program,  or  by  reason  of  an  event  previ- 
ously specified  by  the  activity  itself  or  some  other  activity.  In  the  state 
diagram,  Fig.  1,  transitions  caused  by  monitor  calls  within  another  program 
are  indicated  by  capital  letters  in  "box"*  transitions  caused  by  direct  system 
calls  from  own  program  are  indicated  by  capital  letters  without  box.  Finally, 
transitions  caused  by  sob  different  event  are  indicated  by  small  letters. 
Incidentally,  there  is  basically  no  important  reason  for  emphasizing  between 
time  events  and  other  events.  A "time  event"  is  similar  to  any  other  event 
(see  definition) : The  occurrence  of  wall  clock  time  exceeding  a predeter- 

mined time,  compared  with,  for  example,  some  other  quantity  exceeding  some  pre- 
determined limit  value.  Consequently,  one  could  have  defined  a unified  set 
of  transitions,  and  they  could  be  dependent  upon  a time  event  or  some  other 
event,  according  to  the  specific  needs. 

*)  r haven't  been  motivated  either*  on  the  contrary,  I have  continuously  been 
opposed  to  a non-mono tonic  order. 
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There  are  some  basic  difficulties  in  FORTRAN,  however,  of  expressing 
general  events  in  simple  ways.  I have, thus,  found  it  necessary,  for  those 
subroutines  dealing  with  general  events,  to  define  the  event  specification 
simply  as  a reference  to  an  array,  where  all  necessary  specifications  are 
found.  This  array  can  hardly  be  standardized  at  the  present  time*  thus  it 
must  be  left  processor-dependent.  Consequently,  the  specification  of  general 
events  is  awkward,  compared  to  how  time  events  can  be  specified.  This  justfies 
the  use  of  separate  procedures  for  time  events:  these  are  in  majority,  and 
they  are  probably  used  most  often}  the  specification  of  time  events  should 
therefore  not  be  unduly  complicated. 

The  set  of  subroutine  calls  included  here  is  believed  to  be  complete  for 
state  transitions  within  the  present  state  model.  Subroutines  like  CHNGE  and 
STTSK , described  in  [3],  are  not  included,  since  they  are  not  linked  to  state 
transitions.  It  should  be  considered  whether  these,  or  similar  subroutines, 
should  be  added  to  the  set.  Some  of  the  subroutine  calls,  included  in  [3] 
and  [6]  are  not  included  because  they  should  be  superfluous  in  the  present 
model.  Among  the  subroutine  calls  vanishing  are  HOLD  and  KELSE.  These  are 
substituted  by  the  more  general  semaphore  calls  VJTS  and  SIGNAL;the  WTS  (WaiT  on 
Semaphore)  is  identical  with  Dijkstra's  P,  while  SIGNAL  is  identical  to 

the  V semaphore  function.  Three  other  calls  are  also  available  for  synchroni- 
zation purposes:  REGION,  REGEND  and  AWAIT}  the  first  two  of  these  are  given 
new  and  more  obvious  names  but  are  otherwise  identical  to  SYNC,  SYNCEND  in  [l]. 
Synchronization  is  explained  further  in  the  introductory  part  of  paragraph  6.12. 
ABORT  is  not  included  because  it  has  been  considered  dangerous,  according  to 
discussions  and  opinions  within  the  committee.  If  found  appropriate  or  neces- 
sary, from  succeeding  discussions,  an  ABORT  call  may  easily  be  appended. 
Personally,  I do  not  find  it  necessary  to  get  involved  in  that  discussion  at 
the  present  time. 

6.1.  Summary  of  subroutine  calls. 

This  paragraph  contains  a summary  of  the  subroutine  calls  described  in  the 
following  paragraphs. 

The  following  terms  and  designations  for  parameters  apply  to  several  of  the 
calls.  If  the  exact  meaning  of  these  parameter  designations  deviates  from 
what  is  defined  below,  it  will  be  marked  specifically  in  the-  detailed  description 
of  the  cal  1 . 
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"caLling  activity"  : The  running  activity,  in  whose  program  the  executed 

subroutine  call  statement  is  contained. 

"calling  program"  : The  program  which  contains  the  executed  subroutine  call 

statement.  See  "calling  activity". 

"object  activity"  : The  activity  that  is  wanted  or  expected  to  be  started, 

stopped,  or  otherwise  affected  as  a consequence  of  a system  subroutine 
call.  It  may  also  be  termed  "the  designated"  activity. 

"object  program"  : Since  all  subroutine  calls  described  here  relate  to 

object  activities,  rather  than  programs , the  term  "object  program"  will 
seldom  be  used.  Where  applicable,  however,  this  term  means  the  program, 
or  a program,  used  by  an  activity  under  its  execution. 

Common  parameter  designations: 

i specifies  the  object  activity.  Corresponding  to  previous  working  papers, 
this  argument  has  been  defined  as  either: 

(a)  an  integer  expression 

or  (b)  a string  of  literals,  designating  an  integer  array  name 
or  (c)  a string  of  literals,  designating  an  identifier  name,  like 
procedure  name. 

The  processor  shall  define  which  of  these  forms  are  acceptable. 

It  might  be  discussed,  however,  if  not  this  list  advantageously  could  be  made 
more  restricted.  The  new  Draft  Proposed  ANSI,  FORTRAN  Standard  X3J3/76  ("FORTREV") 
contains  a clear  definition  of  "Names"  and  their  scope.  Even  though  "activity" 
is  not  mentioned  in  X3J3/76,  FORTRAN'S  definition  of  names  fits  very  well,  for 
activities  as  well  as  for  Programs,  Subroutines, etc.  Thus,  the  author  feels 
it  appropriate  now  to  take  advantage  of  the  definitions  of  X3J3/76,  and  simply 
require  the  argument  "i"  to  be: 

"The  name  of  the  object  activity". 

Accordingly,  I have  simplified  the  text  of  the  subsequent  paragraphs,  as  compared 
to  the  previous  edition  of  this  document. 


1 


r 
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in  is  set  on  return  to  the  calling  program,  to  indicate  the  disposition  of 
the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted 

2 or  greater  : request  rejected 

This  argument  shall  be  an  integer  variable  or  integer  array  element,  local 
to  the  calling  program. 


Topic  for  discussion:  The  numerical  definitions  above  are  according  to  all 

previous  working  documents.  Why  can't  the  values  be  the  following,  however?: 

less  than  0 : undefined 

0 : request  accepted 

1 or  greater  : request  rejected. 

The  author  feels  that  the  last  list  conforms  more  to  common  testing  practice: 

In  assembly  languages,  for  example,  the  testing  on  zero  or  not  is  by  far  the 
simplest,  zero  indicating  a "normal"  situation.  Even  though  most  FORTRAN  com- 
pilers might  not  take  advantage  of  the  ease  of  zero  testing  directly,  most  pro- 
grammers are  perhaps  used  to  consider  value  zero  to  represent  normal  return.  I 
have  not  changed  the  proposed  text  in  the  subsequent  paragraphs  however*  I will 
await  the  outcome  of  a discussion. 

The  list  of  subroutine  calls,  described  in  detail  in  subsequent  paragraphs 

is: 


Full  description 

, call : 

in  paragraph: 

§ 6.2  CALL  CREATE  (h,i,j,m) 


§6.3  CALL  KILL  (i, j,m) 

(opposite  of  CREATE) 

§ 6.4  CALL  START  (i,j,k,m) 

(relative  time) 

§6.5  CALL  TRNON  (i,j,m) 

(absolute  time) 


parameters : 

h : input  name  of  created  activity 

i : return  designation  of  created 
activity 

j : descriptor  of  associated  program 

j : termination  parameters 

j : numerical  value  of  time  delay 

k : time  unit 

j : reference  to  absolute*  time 
descriptor  for  activation 
instant 
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§ 6.6.1 

§ 6.6.2 

§ 6.7 
§ 6.8 

§ 6.9 
§ 6.10 
§ 6.11 

§ 6.12.1 
§ 6.12.2 
§ 6.12.3 

§ 6.12.4 
§ 6.12.5 

§ 6.13 


CALL  CYCLE  ( i , j ,k , 1 ,m) 
(cyclic,  with  delayed  first 
activation) 


CALL  TCYCLE  (i,j,k,l,m) 
(cyclic,  with  absolute  time 
spec,  of  first  activation) 


CALL  CON  (i , j ,k) 

(connection  to  event  ) 

CALL  DECYCLE  (i ,m) 

(termination  of  periodic 
re -activation) 

CALL  DECON  (i,j,m) 

(eliminate  event  connection) 

CALL  CANCL  (i,m) 

(eliminate  scheduling) 

CALL  WAIT  ( j ,k ,m) 

(delay  continuation  of  calling 
activity) 

CALL  WTS  (s,m) 

(wait  on  semaphore) 

CALL  SIGNAL  (s,m) 

(release  semaphore) 

CALL  REGION  (v,p,j,m) 

(entry  of  conditional  critical 
region) 


CALL  REGEND  (v,m) 

(textual  terminator  of  critical 
region  in  program  text) . 

CALL  AWAIT  (v,j) 

(wait  for  event) 


j : length  of  time  interval 
k : time  unit 

1 : time  delay  before  first 
activation 

i,j,k,m:  identical  with  param.of 
CYCLE 

1 : reference  to  absolute  time 

descriptor  for  activation  instant 

j : reference  to  event  descriptor, 
j : like  CON 


j : length  of  time  delay 

k : time  unit 

s : semaphore  variable 
(shared  integer) 

s:  semaphore  variable 

v : critical  region  designator 

p : priority 

j : event,  condition  for  entrance 
to  the  critical  region 

v : critical  region  designator 

v : critical  region  designator, 
or  zero. 

j : event  specification  for 
resumed  execution 


CALL  EXIT 

(termination  of  execution) 
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fe.2.  Creation  of  a new  activity. 

A new  activity  is  introduced  to  the  real-time  system  by  reference  to  sub- 
routine CREATE.  The  designated  activity  will  be  associated  with  some  specified 
program,  considered  a resource  like  other  resources , necessary  for  the  activity 
to  perform.  The  associated  program  will  normally  reside  on  some  background 
storage  unit,  administered  by  a file  system.  It  may  also  be  read  in,  for 
example  from  paper  tape  in  simple  systems,  fetched  from  some  separate  place 
in  the  primary  memory,  etc.,  depending  on  parameter  j of  the  call.  Subject 
to  restrictions  by  the  processor,  new  activities  may  be  created  recursively. 

Thus,  the  same  name  (parameter  h)  may  be  specified  as  another  activity,  al- 
ready in  existence.  For  the  purpose  of  being  able  to  distinguish  between 
similar  activities,  the  executive  system  will  supply,  as  return  parameter  i, 
a unique  identifying  name.  This  name,  rather  than  parameter  h, should  be  used 
as  identifier  in  all  succeeding  system  calls  for  state  transitions  of  the 
created  activity.  If  the  processor  denies  recursive  creation  of  activities, 
it  will  be  natural  to  expect  the  executive  system  to  return  a name  i identical 
to  the  input  name  h. 

The  form  of  the  call  is: 

CALL  CREATE  (h,  i,  j,  m) 

where 

h specifies  an  input  name  of  the  created  object  activity.  If  this  parameter 
is  identical  to  the  actual  name  of  an  already  existing  activity,  the 
executive  system  shall  interprete  this  as  a requirement  for  a new  activity 
of  the  same  type  as  the  former.  The  argument  is  either  the  name  of  the 
object  activity  or  an  array  name. 

i is  set  on  return  to  the  calling  program,  as  a unique  designating  name  or 
identifier  for  the  created  activity,  supplied  by  the  executive  system. 

This  identifier  is  to  be  used  in  future  reference  of  the  designated  activi- 
ty, as  long  as  it  remains  existent  in  the  real-time  system.  The  argument 
will  be  of  the  same  form  as  parameter  h. 

j specifies  an  integer  array  which  contains  all  information  necessary 

to  specify  an  associated  program:  its  desi gnati on .where  the  program  can 
be  found  such  as  description  of  file,  residency  while  existent  (core 
resident  or  swappable)  etc.  The  details  are  processor-defined. 
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m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition  of 
the  request  as  follows: 

0 or  less  : undefined. 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element, 
local  to  the  call. 

6.3.  Eliminating  an  activity  from  the  real-time  system. 

A reference  to  subroutine  KILL  will  eliminate  a designated  activity  from 
the  real-time  system,  by  transferring  it  to  state  NON-EXISTENT.  If  the  designated 
activity  is  in  state  DORMANT  or  PENDING,  the  effect  shall  be  carried  out  immedi- 
ately. If  the  designated  activity  is  in  any  executing  state,  the  termination 
shall  only  affect  future  executions.  Thus,  the  designated  activity  will  conclude 
its  present  execution,  without  any  intervention  by  this  call. 

The  processor  may  impose  certain  restrictions  on  which  calling  activities 
may  be  permitted  to  eliminate  other  activities.  For  example,  a reference  to 
subroutine  KILL  may  be  effective  only  if  the  designated  activity  has  been 
created  by  the  same  calling  activity,  i.e.  there  exists  a parent  - child  relation- 
ship. 


The  form  of  the  call  is: 
CALL  KILL (i , j , m) 


where 

i specifies  the  activity  to  be  affected  (object  activity) . The  argument 
is  either  the  name  of  the  object  activity  or  an  array  name. 


j 


m 


specifies  an  integer  array  which  contains  information  to  guide  the 
termination,  such  as  whether  the  object  program  is  to  be  written  to  some 
background  storage,  the  location  or  file  name  within  such  storage, 
etc.  The  specific  details  are  processor-defined. 

is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted.  The  designated  activity  (i)  is 

terminated. 
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2 : request  accepted,  but  the  activity  is  still  executing 

within  a run  already  started  prior  to  the  call. 

3 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 


6.4  Starting  an  Activity  Immediately  or  after  a Specified  Time  Delay. 

Execution  of  a reference  to  the  subroutine  START  shall,  after  the  expira- 
tion of  the  specified  time  delay,  cause  the  execution  of  the  designated  activity's 
first  program  unit.  This  execution  shall  commence  at  the  program's  first 
executable  statement.  The  time  delay  is  defined  as  the  nominal  duration  from 
the  time  the  call  is  made  until  the  time  the  designated  activity  is  supposed 
to  enter  state  RUNNING.  In  the  meantime  . the  designated  activity  is  listed 
in  a table,  and  is  transferred  to  state  PENDING  if  the  present  state  is,  or 
when  it  becomes,  DORMANT.  The  actual  time  instants  for  the  entering  and  the 
leaving  of  the  state  PENDING  are  subject  to  the  resolution  of  the  system's 
real  time  clock,  to  the  interrogating  and  activating  actions  performed  by 
the  Executive  program,  and  to  the  possibility  that  the  present  state  is  not 
DORMANT.  Thus,  a reference  to  subroutine  START  is  not  necessarily  equivalent 
to  a transfer  to  state  PENDING,  but  to  a request  of  such  a transfer,  when  it  be- 
o ;nes  perm  i ssibl  . A specified  zero  or  negative  delay  shall  be  interpreted  as 
"immediate  execution”,  which  shall  cause  any  residency  in  state  PENDING  to 
vanish  or  be  as  short  as  possible.  The  form  of  the  call  is: 

CALL  START ( i , j , k , m) 

where 

spe  i fie-  the-  activity  to  be  executed.  The  argument  is  either  the 

najiif  of  tii  object  activity  or  an  array  name. 

j specifies  the  time  delay,  in  units  an  specified  by  k,  and  as  defined 

above.  This  argument  shall  be  an  . nteger  expression. 

k specifies  the  units  of  time  as  follows: 

0 - Basic  counts  of  the  system's  real  time  clock 

1 - Milliseconds 

2 - Seconds 

3 - Minutes 

4 - Hours 


be  an  int-  ger  ex|  re.,  ion. 


Th i s a rgumen t 
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m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition  of 
the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 

6.  5 Starting  an  Activity  at  a Specified  Absolute  Time. 

Execution  of  a reference  to  the  subroutine  TRNON  shall  cause  the  designated 
activity's  first  program  unit  to  be  executed  at  a specified  time  (absolute 
time).  Execution  of  the  object  program  will  conmence  at  the  program's 
first  executable  statement.  The  specified  time  shall  be  the  time  when  the  object 
activity  is  supposed  to  enter  state  RUNNING,  and  the  actual  time  of  this  occurrence 
is  subject  to  the  resolution  of  the  system's  real  time  clock  and  to  the  inter- 
rogating and  activating  actions  performed  by  the  Executive  program.  The 
relations  topending-table  and  to  transitions  between  states  DORMANT,  PENDING, 
and  RUNNING  are  similar  to  those  described  for  subroutine  START.  The  form  of 
this  call  is: 

CALL  TRNON (i,  j , m) 

where: 

i specifies  the  activity  to  be  executed  (object  activity) . The  argument  j 

is  either  the  name  of  the  object  activity  or  an  array  name. 

j Designates  an  array,  whose  first  6 elements  contain  the  absolute  J 

time  at  which  the  object  program  is  to  be  executed.  These 


elements 

are  as 

follows: 

First  element  : 

Seconds 

(0 

to 

59) 

Second 

•* 

Minutes 

(0 

to 

59) 

Third 

ii  , 

Hours 

(0 

to 

23) 

Fourth 

H . 

Day 

(0 

to 

31) 

Fifth 

n , 

Month 

(0 

to 

12) 

(0  -*) 


Sixth 


Year 


-76- 


Any  negative  value  is  interpreted  as  zero,  and  any  value  greater  than 
the  upper  limits  specified  above  shall  be  taken  as  equal  to  the  limit. 
Value  zero  for  "Day",  "Month"  or  "Year"  shall  be  interpreted  as  current 
day/  month  and/or  year  and  should  be  changed  to  correct  values  auto- 
matically by  the  executive  system. 

Ibis  argument  shall  be  an  integer  array  name. 

Time  is  interpreted  as  "current  local  time". 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 


6.6 Starting  an  Activity  in  Periodic  Execution. 


6.6.1  Initial  start  immediately  or_after  a specified  time  delay. 


Execution  of  a reference  to  the  subroutine  CYCLE  has  the  same  immediate 

effect  as  a reference  to  subroutine  START.  Additionally,  the  designated 

1 ) 

activity  shall  be  re-scheduled  , each  time  the  activity  leaves  state  PENDING. 
The  new  time  scheduled  shall  be  equal  to  the  sum  of  previous  scheduled  time 
and  the  interval  specified  by  the  call  of  CYCLE.  The  re-scheduling  under  said 
condition  will  continue  until  actively  terminated  by  a call  of  subroutine 
DECYCLE,  thus  stopping  a series  of  periodic  executions.  After  such  a termin- 
ation, a new  cyclic  execution  of  the  designated  activity  will  require  new  call 
of  CYCLE.  The  interval  can  be  modified  by  another  call  of  CYCLE,  without  an 
intervening  call  of  DECYCLE.  This  modification  shall,  however,  affect  only 
succeeding  scheduling  operation,  i.e.  it  shall  not  change  the  current  interval 
and  the  execution  which  is  already  scheduled;  the  "delay"  parameter  of  a modi- 
fying CYCLE  call  is  without  effect.  If  the  "delay"  parameter  shall  have  effect, 
the  previous  cycling  must  first  be  terminated  Ly  a reference  to  subroutine 

DECYCLE.  In  this  case,  it  will  usually  also  be  appropriate  to  eliminate  the 
previous  schedul tng  c mpletely,  by  a call  of  subroutine  CANCL. 

1 ) ".scheduled"  (written  with  snail  letters)  is  hi  re  in  th«.  meaning  of  "listed  in 
t i.e  pending  • • ibl  ",  u oppost  : t »te  PENDING . T)  e distinction  is  expl  a 
in  section  1. 
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The  actual  running  may  be  delayed  unintentionally,  while  in  state  RUNNING, 

because  of  running  of  other  programs.  Such  delays  will  not  be  accumulated. 

If  the  execution  is  not  finished  before  the  time  for  next  execution,  the  next 

execution  will  be  delayed  and  started  (re-scheduled)  as  soon  as  the  previous 

? ) 

execution  is  finished  . 


The  form  of  the  call  is: 

CALL  CYCLE (i,  j,  k,  1,  m) 

where: 

i specifies  the  activity  to  be  executed.  The  argument  is  either  the 
name  of  the  object  activity  or  an  array  name. 

Object  and  calling  activity  may  be  the  same,  i.e.  argument  "i" 
may  designate  the  calling  activity. 

j specifies  nominal  length  of  the  time  interval,  in  units  as  specified 
by  k , and  as  defined  above.  This  argument  sjall  be  an  integer 
expression . 


It  should  be  discussed,  how  far  such  skewing  effects  may  go  before  some  alarm 
i:  generated.  It  should  also  be  discussed,  how  an  alarm  can  be  implemented. 
One  possibility,  quite  elegant  with  the  present  handling  of  programmed  events, 
would  be  to  affect  parameter  m of  the  cycle-call.  This  could,  in  turn,  be 
used  as  a triggering  event  for  a fault-handling  program,  initiated  by  CON. 

The  effect  would  be  that  a sudden  change  of  m to, say,  3,  would  start  the 
fault-handling  program. 

Example : 

CALL  CYCLE  (INTERGRATE,  2,1, FI) 


CALL  CON (FAULT] ,FA1 ,m) 


A suitable  description  in 
array  FA1  could  be: 


l £ 
of 


this  mechanism 
the  cycle-call 


FI  3 ' 

1 

is  allowed,  the  description  of  parameter  m (5th 
should  be  modified  accordingly. 


parameter) 
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k specifies  the  units  of  time  as  follows: 

0 - Basic  counts  of  the  system's  real  time  clock 

1 - M lliseconds 

2 - Seconds 

3 - Minutes 

4 - Hours 

This  argument  shall  be  an  integer  expression. 

1 specifies  a time  delay,  in  units  as  specified  by  k,  for  the  initial 
activation,  as  measured  from  the  time  the  call  was  made.  The  time 
delay  shall  be  interpreted  like  parameter  j in  call  of  subroutine 
START. 

This  argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 

6. b12__lnitial_start_at  specified_absolute  time. 

Execution  of  a reference  to  the  subroutine  TCYCLE  has  the  same  immediate 
effect  as  a reference  to  subroutine  TRNON . Additionally,  the  designated  activity 
shall  le  re-scheduled  1 ^ , each  time  the  activity  leaves  state  PENDING. 

The  cyclic  rescheduling  is  exactly  identical  to  this  function  of  subroutine 
CYCLE , described  in  section  6.5.1.  The  interval  can  be  modified  by  another  call 
to  TCYCLE,  or  tc  CYCLE,  with  identical  results  as  described  in  sec.  6.5.1. 

The  form  of  the  call  is: 

CALL  TCYCLE (i,  j,  k,  1,  m) 

whe re : 

i,  j,  k and  m are  identical  with  the  corresponding  parameters  of  call  to 
subroutine  CYCLE  (see  sec. 6. 6.1.),  1 designates  an  array,  whose  first  6 

elements  contain  the  absolute  time  at  which  the  spec . f„od  activity  is 
supposed  to  enter  state  RUNNING.  This  argument  is  . x.ctly  equivalent  t 

ITT  , . . 

See  footnote  J l qr  .( 


First 

element 

Seconds 

(0 

to 

59) 

Second 

II 

: Minutes 

(0 

to 

59) 

Third 

II 

: Hours 

(0 

to 

23) 

Forth 

II 

: Day 

(0 

to 

31) 

Fifth 

II 

: Month 

(0 

to 

12) 

Sixth 

II 

: Year 

(0 

-*  ) 

Any  negative  value  is  interpreted  as  zero,  and  any  value  greater  than  the 
upper  limits  specified,  shall  be  taken  as  equal  to  the  limit.  Value  zero  for 
"Day",  "Month"  or  "Year"  shall  be  interpreted  as  current  day,  month  and/or 
year  and  should  be  changed  to  correct  values  automatically  by  the  executive 
system.  This  argument  shall  be  an  integer  array  name.  Time  is  interpreted 
as  "current  local  time". 


Execution  of  a reference  to  subroutine  CON  shall  cause  the  designated 
activity  to  be  associated  with  a specified  event  and  listed  with  a new  entry 
in  the  schedule-table.  This  listing  shall  cause  the  transition  to  state 
PENDING  if,  or  when,  the  designated  activity  is  or  arrives  in  state  DORMANT. 
The  specified  event  shall  constitute  the  condition  for  the  subsequent  transfer 
to  state  RUNNING.  The  form  of  this  call  is: 

CALL  CON ( i , j,  m) 

whe  re : 

i specifies  the  activity  to  be  affected.  The  argument  is  either  the 
name  of  the  object  activity  or  an  array  name. 


1 


specifies  en  integer  array  which  contains  all  the  information 
necessary  to  designate  the  event  to  be  connected  and  the  type  of 
connection . 


i 
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is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 


0 or  less 


2 or  greater 


undefined 
request  accepted, 
request  rejected. 


This  argument  shall  be  an  integer  variable  or  integer  array  element . 


6 . 8.  Terminating  periodic  execution. 

Execution  of  a reference  to  the  subroutine  DECYCLE  shall  terminate  any 
periodic  re-sheduling  of  a designated  activity,  previously  initiated  by  a 
call  of  subroutine  CYCLE  or  TCYCLE.  If  the  designated  activity  is  PENDING  or 
in  any  executing  state,  i.e.  RUNNING  or  SUSPENDED,  the  termination  shall  affect 
only  future  executions.  Thus,  the  designated  activity  will  conclude  its  present 
and  pending  execution,  without  any  intervention  by  this  call.  The  form  of  the 


CALL  DE CYCLE  (i,ir.) 


i specifies  the  activity  to  be  affected.  The  argument  is  either  the 
name  of  the  object  activity  or  an  array  name. 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 


0 or  less 


undefined 

request  accespted.  The  object  activity  is  not  running, 
request  accepted,  but  the  activity  is  still  executing 
within  a run  already  started  prior  to  the  call. 


3 or  greater  : request  rejected. 


This  argument  shall  be  an  integer  variable  or  integer  array  element. 


-81- 


&.’■>.  Elimination  of  an  event  connection. 

Execution  of  a call  to  subroutine  DECON  shall  cancel  any  connection  be- 
tween a designated  activity  and  a specified  event.  Thus,  it  eliminates  further 
effects  from  a previous  call  to  subroutine  CON.  If  the  object  activity  is 
in  any  executing  state,  the  termination  shall  affect  only  future  executions. 
Thus,  the  object  activity  will  conclude  its  present  execution,  without  any 
intervention  by  this  call.  The  form  of  the  call  is: 


whe  re : 


CALL  DECON  (i,  j,  m) 


i  specifies  the  activity  to  be  affected.  The  argument  is  either  the  name 
of  the  object  activity  or  an  array  name. 


specifies  an  integer  array  which  contains  all  the  information 
necessary  to  designate  the  event  which  is  to  be  deconnected. 

is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted.  The  object  activity  is  not 

running. 

2 : request  accepted,  but  the  activity  is  still  executing 

within  a run  already  started  prior  to  the  call. 

3 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 


6.10.  Elimination  of  previous  scheduling. 


Execution  of  a reference  to  subroutine  CANCL  shall  cancel  all  effects  of 
previous  calls  to  subroutines  START,  TRNON,  CYCLE , or  TCYCLE  for  a designated, 
object  activity.  i 


If  the  object  activity  is  in  any  executing  state  (RUNNING  og  SUSPENDED) , the 
elimination  shall  affect  only  future  executions.  Thus,  the  designated  program 
will  conclude  its  present  execution,  without  any  intervention  by  this  call. 

The  form  of  the  call  is: 

CALL  CANCL  (i,m) 


where : 

i specifies  the  activity  to  be  affected  (object) . The  argument  is  either 
the  name  of  the  object  activity  or  an  array  name. 


m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted.  The  object  activity  is  not  running. 

2 : request  accepted,  but  the  activity  is  still  executing 

within  a run  already  started  prior  to  the  call  or  has 
still  more  entries  in  the  pending- table , as  consequences 
of  previous  calls  of  subroutine  CON. 

3 or  greater  : request  rejected. 


This  argument  shall  be  an  integer  variable  or  integer  array  element. 


6.11.  Delaying  Continuation  of  an  Activity. 


Execution  of  a reference  to  the  subroutine  WAIT  shall  provide  a means 
whereby  a running  activity  is  suspended  for  a specified  length  of  time.  After 
the  suspending  period,  the  program  shall  resume  execution,  first  executing 
the  instruction  immediately  following  the  call  of  subroutine  WAIT. 

The  time  delay  is  defined  as  the  nominal  duration  from  the  time  instant 
when  the  call  was  made  until  the  program  resumes  execution  in  its  virtual 
processor,  by  being  transferred  to  state  RUNNING.  The  actual  time  instants  for 
the  entering  and  leaving  states  RUNNING  and  SUSPENDED  are  subject  to  the  re- 
solution of  the  system's  real  time  clock  and  to  the  interrogating  and  activating 
actions  performed  by  the  Executive  system.  A specified  zero  or  negative  delay 
shall  be  equivalent  to  no  action,  i.e.  immediate  return  from  subroutine  WAIT. 

The  form  of  the  call  is: 

CALL  WAIT ( j , k,  m) 

where : 

j specifies  the  length  of  time  delay,  in  units  as  specified  by  k,  and 

as  defined  above.  This  argument  shall  be  an  integer  expression. 

k specifies  the  units  of  time  as  follows: 

0 - Basic  counts  of  the  system's  real  time  clock 

1 - Millisecond: 

2 - Seconds 

3 - Minutes 

4 - Hours 

This  argument  shall  be  an  integer  expression. 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 

of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  or  integer  array  element. 


6.12.  Synchronizing  suspension  of  an  activity. 


Syncronization  between  two  parallel  activities  is  achieved  by  transfer  of 
one  activity  into  state  SUSPENDED  while  waiting  for  certain  conditions  to  be 
satisfied  by  the  other. 

A number  of  different  mechanisms  for  synchronization  are  proposed  in  the 
literature;  each  one  with  its  attributes  and  claimed  advantages.  ([4],  [7],  to 
[ 1 3 ] ) . Here  is  proposed,  to  include  in  this  standard  of  FORTRAN  subroutine  calls, 
two  widely  used  mechanisms:  Semaphores  and  Conditional  critical  regions.  Each 

of  these  mechanisms  has  its  class  of  problems,  for  which  it  is  optimal  in  com- 
parision  with  the  other.  It  is  generally  acknowledged,  that  all  synchronization 
problems  may  be  solved  by  proper  use  of  any  one  of  them,  and  it  is  reasonable 
to  assume,  that  these  two  mechanisms  will  be  sufficient,  also  from  a practical 
point  of  view. 

Semaphores  are  traditionally  manipulated  by  Dijkstra's  P and  V primi- 
tives. Although  these  primitives  are  widely  known  by  these  terms,  single  letter 
identifiers  should  be  avoided,  since  they  can  be  confused  with  user  defined 
names.  Thus,  the  semaphore  manipulating  subroutine  calls  are  here  described, 
using  the  suggested  designations  WTS  (WaiT  on  Semaphore) , and  SIGNAL, 
corresponding  to  P and  V respectively. 

Conditional  critical  regions  as  means  of  synchronization  are  described 
by  P.  Brinch  Hansen  in  [4]  and  [10]  and  convincingly  advocated  as  particularly 
well  suited  for  problems  where  several  activities  compete  for  exclusive  access 
to  shared  resources.  The  author  of  the  present  paper  lias  developed  the  principle 
further  ( 1 1 3 ] ) , by  attaching  priority  to  a call  for  entry  into  a critical  region. 
In  this  paper,  conditional  critical  regions  with  priority  are  managed  by  two 
system  subroutine  calls,  REGION  and  REGEND. 

Although  theoretically  superfluous  because  of  the  other  synchronizing  sub- 
routine calls,  it  is  useful  from  a practical  aspect  to  extend  the  list  of 

synchronization  calls  to  include  AWAIT: "Wait  on  event".  Any  event  can  be  speci- 
fied, and  upon  occurrence,  the  designated  activity  is  transferred  from  state 
SUSPENDED  and  back  to  RUNNING. 

The  following  paragraphs  describe  in  detail  the  five  subroutine  calls  for 
the  synchronizing  mechanisms  mentioned  in  the  introduction  above. 
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6.12.1.__  Wait  on_Semaphore . 

Execution  of  a reference  to  subroutine  WTS  involves  manipulation  on  a non- 
negative integer  variable,  referred  to  by  one  of  the  arguments  of  the  call, 
and  shared  with  other,  parallel  activities.  This  particular  shared  variable 
is  termed  a "semaphore",  and  the  immediate  effect  of  the  subroutine  call  de- 
pends on  the  magnitude  of  the  semaphore,  as  decribed  below.  The  operation  on 
the  semaphore  shall  be  exclusive,  i.e.  only  one  activity  at  a time  may  access 
the  semaphore  * ^ 

The  form  of  the  call  of  WTS  is: 

CALL  WTS  (s,m) 

where : 

s specifies  an  integer  variable,  termed  the  "semaphore"  and  shared  with 
the  parallel  activities  with  which  the  calling  activity  is  to  be  syn- 
chronized. The  subroutine  shall  be  granted  exclusive  access  to  this 
variable  during  its  operation.  If  s is  zero  when  the  subroutine  is 
called,  the  calling  activity  will  be  transferred  into  state  SUSPENDED  and 
the  exclusive  access  rights  will  be  released.  An  activity  thus  suspended 
will  resume  state  RUNNING  when  the  semaphore  becomes  positive  again.  At 
this  point,  subroutine  WTS  will  perform,  on  behalf  of  the  calling  activity, 
the  operation,  exclusive  in  time: 
s = s - 1 

and  a return  is  made  to  the  calling  program.  If  the  calling  activity  is  not 
suspended  because  s>0 , the  operation  s=s-l  will  be  performed  directly, 
without  any  intervening  suspension. 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition  of 
the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted,  synchronization  obtained. 

2 or  greater:  request  rejected,  synchronization  is  not  performing  as  expected 
This  argument  shall  be  an  integer  variable  or  integer  array  element. 


*)  A somewhat  less  restrictive  rule  may  be  imposed,  in  fact:  Simultanous  reading 

may  be  allowed.  This  is  of  no  concern  in  the  present  context,  however. 
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6.12.2  _Release_of  Semaphore. 

Execution  of  a reference  to  the  subroutine  SIGNAL  snail  increment  an  integer 
variable,  referred  to  by  one  of  the  arguments  of  the  call,  and  shared  with  other 
activities.  If  this  incrementation  causes  the  numerical  value  to  change  from 
zero  to  positive,  this  event  shall  cause  the  transtition  to  state  RUNNING 
for  any  other  activity,  waiting  in  state  SUSPENDED  for  the  occurrence  of  this 
event,  relating  to  the  same  variable.  The  form  of  this  call  is 

CALL  SIGNAL  (s,m) 

where: 

s specifies  an  integer  variable,  shared  with  the  parallel  activities 
with  which  the  calling  activity  is  to  be  synchronized.  The  sub- 
routine shall  be  granted  exclusive  access  to  this  variable  during 
its  operation  and  will  execute  the  following  modification  of  its 
value: 

s = s + 1 

A change  from  zero  to  positive  value,  caused  by  this  opera- 
tion, shall  provide  a releasing  transfer  to  state  RUNNING  for  any 
parallel  activity  waiting  in  state  SUSPENDED  for  this  event  to  occur. 

m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : requested,  synchronization  obtained. 

2 or  greater  : request,  rejected,  synchronization  is  not  performing 

as  expected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 
t>_.  12 . 2 . Entry  of_Cond.itional  Critical  region. 

Execution  of  a reference  to  the  subroutine  REGION  is  a request  from  an 
activity  to  be  granted  access  to  its  critical  region,  named  as  per  argument  v. 
The  request  is  guided  by  a priority  number  supplied  as  argument  p.  The  effect 
of  the  call  is  that  the  activity  is  transferred  to  state  SUSPENDED  where  it 
shall  remain  until  access  to  the  critical  region  is  granted.  At  this  time,  it 
will  be  transferred  to  state  RUNNING.  One  condition  for  access  to  the  critical 
region  will  be  an  event,  specified  as  argument  j.  The  release  for  transfer 


i 
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to  state  RUNNING  shall  not  be  performed  until  all  the  following  conditions  are 
satisfied: 

1)  v is  not  assigned  to  another  activity 

2)  The  event,  specified  by  j , is  true. 

3)  If  more  than  one  of  concurrently  executing  parallel  activities  are 
simultaneously  calling  REGION, with  the  same  parameter  v,  that  one 
having  the  highest  value  of  p,  among  those  activities  where  all 
these  conditions  are  satisfied,  shall  be  selected  for  entrance  into 
the  critical  region.  This  selection  is  indicated  by  assigning  v to 
this  activity,  thereby  preventing  point  1 to  be  satisfied  for  the 
other  activities.  If  the  priority  p has  the  same  value  for  several 
activities,  these  activities  will  be  selected  in  the  order  of  their 
arrival  to  the  queue. 

The  satisfaction  of  these  conditions  constitutes  the  event  upon  which  the 
activity  can  be  transferred  from  state  SUSPENDED  to  RUNNING.  At  this  point, 
the  activity  will  have  entered  its  critical  region. 

The  form  of  this  call  is: 

CALL  REGION (v,  p,  j,  m) 

whe  re : 

v specifies  an  integer  variable,  shared  with  the  concurrent  programs 
to  be  synchronized.  This  parameter  designates  the  critical  region. 

p specifies  a priority  and  can  be  either 

a)  an  integer  expression  or  variable 

or  b)  an  integer  constant 

in  any  case,  the  value  of  p shall  be  defined,  prior  to  the  call. 

j specifies  tlie  event  which  constitutes  a condition  for  the  entrance 
to  the  critical  region,  as  listed  below.  The  argument  is  either: 
a)  a real  constant:  value  >0  implies  the  QVint  is  true;  this  is 
normally  used  for  unconditional  entry, 
or  b)  a real  expression:  value  ^ 0 constitutes  the  ivent. 
or  c ) an  integer  array  name;  the  array  contains  all  the  information 
necessary  to  specify  tne  event. 

The  processor  shall  define  which  of  these  forms  are  acceptable,  and 
the  processor  also  defines  the  specific  form  of  array  components, 
if  applicable. 
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m is  set  on  return  to  the  calling  program,  to  indicate  the  disposition 
of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  variable  or  integer  array  element. 


6.12.4  Exit  from  Critical  region. 


When  an  activity  has  entered  a critical  region,  and  a common  variable  v 
is  assigned  to  it,  this  region  can  only  be  released,  and  v deassigned,  by  the 
same  activity,  by  call  of  subroutine  REGEND  (or  as  a secondary  effect  of  a call 
of  AWAIT,  see  next  section) . The  region,  and  the  assignment  of  v,  are  con- 
sidered similar  to  internal  resources;  thus  the  activity  will  formally  remain 
in  state  RUNNING  during  and  immediately  after  this  call.  The  form  of  the 
call  is: 

CALL  REGEND (v,  m) 

whe  re : 

v is  the  same  variable  as  in  a previous  call  of  REGION. 

m is  set  on  return  to  the  calling  activity,  to  indicate  the  dispostion 

of  the  request  as  follows: 

0 or  less  : undefined 

1 : request  accepted. 

2 or  greater  : request  rejected. 

This  argument  shall  be  an  integer  varable  or  integer  array  element. 

When  the  subroutine  REGEND  is  entered,  v will  immediately  be  deassigned  from 
the  calling  activity  thereby  exiting  the  calling  activity  from  the  critical 
region,  and  permitting  v to  be  assigned  to  another  activity,  pending  in  its 
call  of  REGION. 


^lii  5*  _Waitir>2_£or  51}  event. 


The  waiting  effect  of  synchronization  is  obtained  through  call  of  sub- 
routine AWAIT,  with  the  following  effect: 

The  activity  is  suspended,  until  an  event  is  true:  The  parameter  j has 

similar  effect  as  in  call  of  REGION;  it  designates  the  event  which  subsequently 
will  permit  the  calling  activity  to  continue  by  being  transferred  to  state 
RUNNING.  The  call  will  have  no  effect,  if  the  specified  event  is  true  already 
when  the  call  is  made.  The  form  of  this  call  is: 

CALL  AWAIT (v,  j) 

where: 

v specifies  an  integer  variable,  shared  with  parallel  activities  to  be 
synchronized  or,  it  can  be  the  integer  0.  This  parameter  designates 
a critical  region  and  can  be  set  equal  to  0 if  the  call  is  not  being 
used  in  connection  with  a critical  region. 

j specifies  the  event  which  constitutes  the  condition  for  the  calling 
activity  to  resume  execution  by  being  transferred  to  state  RUNNING. 
The  argument  is  either: 

a)  an  integer  expression:  value  > 0 constitutes  the  event. 

or  b)  an  integer  array  name;  the  array  contains  all  information 
necessary  to  specify  the  event. 

The  processor  shall  define  which  of  these  forms  are  acceptable,  and 
the  processor  also  defines  the  specific  form  of  array  components,  if 
applicable . 

If  the  activity  is  within  its  critical  region,  designated  by  v,  it  shall  leave 
this  critical  region  immediately  and  permanently  when  AWAIT  is  entered,  and  v 
shal  l be  deassigned.  Thus,  subroutine  AWAIT  includes  the  effect  of  REGEND. 

This  ensures  that  concurrent  activities,  competing  for  the  same  critical 
region,  are  not  unduly  delayed  if  the  programmer,  inadvertently,  puts  the  call 
of  AWAIT  inside  the  program  section  corresponding  to  the  critical  region.  The 

only  purpose  of  specifying  the  critical  region,  by  v,  is  to  achieve  this  auto- 
matic leaving  of  the  critical  region.  Thus,  it  can  be  omitted  or,  the  effect 
specifically  suppressed,  by  using  the  integer  0.  It  would,  however,  be  a 
good  practice  to  always  include  the  region  specification,  if  applicable. 
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6.12.6.  An  alternative  definition  of  critical  region  call. 


If  the  call  of  subroutine  REGION^ is  extended  with  a fifth  parameter,  it  is 
possible  to  eliminale  the  use  of  REGEND  to  terminate  the  scope  of  a critical 
region.  The  subroutine  REGEND  then  becomes  superfluous  and  can  be  delected 
completely  from  the  set  of  standard  subroutines.  The  new  definition  of  the  form 
of  the  call  of  REGION  could  be: 


CALL  REGION  (v,  p,  j,  1,  ra) 


where  v,  p,  j and  m are  as  defined  in  section  6.12.3. 

1 specifies  a statement  label,  indicating  the  last  statement  of  the  critical 
region.  1 is  an  integer  variable  name. 

The  statement  label , indicating  the  end  of  the  critical  region, must  be  assigned  to 
parameter  1 by  a statement  label  assignment  statement, i.e . a statement  of  the  form 


ASSIGN  s TO  1 


where  £ is  the  statement  label  indicating  the  end  of  the  critical  region.  For  the 
assignment  statement,  all  normal  rules  from  ANS  FORTRAN  applies. 


It  should  be  discussed,  which  of  the  forms  of  REGION  should  be  included  in 
the  standard:  The  pair  REGION  - REGEND  as  described  in  sections  6.12.3  and 

6.12.4,  or  the  alternative  form  of  REGION  as  described  in  the  present  section 
and  which  makes  REGEND  superfluous.  Both  methods  give  the  same  number  of 
statements  in  a program,  and  about  the  same  number  of  rules  to  remember  for  the 
programmer.  The  method  with  assignment  of  a label  appears  to  give  slightly 
shorter  execution  time,  since  it  eliminates  one  run-time  call  of  a subroutine. 
This  saving  is  probably  only  fictitious,  however:  At  the  termination  of  the 

critical  region,  the  executive  system  must  be  interrogated  in  any  way,  to  re- 
lease the  region  v for  the  benefit  of  other  parallel  activities.  Perhaps  this 
method  even  gives  slightly  increased  execution  time,  because  the  executive 
system  must  be  furnished  with  some  mechanism  to  keep  track  of  the  execution  of 
the  region,  to  terminate  the  region  when  the  last  statement  is  reached.  In  any 
way, the  realization,  with  regards  to  compiler  and  executive  system,  will  probably 
be  more  complicated  with  the  method  in  the  present  section.  Since  the  advantage 


r 

[ 


for  the  user  is  probably  also  questionable  I see  no  reason  at  present  time 
of  the  evaluation  work  to  propose  this  method.  It  would  be  interesting  to 
see  other  opinions,  however. 


6.13.  Normal  termination  of  execution. 

Execution  of  a call  to  subroutine  EXIT  shall  terminate  the  normal  execution 
of  an  activity  and  return  the  activity  to  state  DORMANT.  The  form  of  the 
call  is: 

CALL  EXIT 

with  no  parameters. 

i 

6.14.  Status  information  of  Pending-queue. 

Execution  of  a call  to  subroutine  QPEND  shall  provide,  on  return,  information 
about  all  elements  of  the  pending-queue  (-table) , regarding  the  designated 
activity. 

The  purpose  is  to  supply,  to  the  calling  activity,  all  pertinent  information 
about  the  designated  activity's  entries  in  the  pending- table , prior  to  the 
call  of  CANCL  or  DECYCLE.  This  will  enable  the  calling  activity  to  reestablish 
those  elements  of  the  table,  that  are  eliminated  unintentionally  by  CANCL  or 
DECYCLE.  The  call  itself  has  no  effect  on  state  transitions. 

The  form  of  this  call  is 

CALL  QPEND  (i,  j) 

whe  re 


i specifies  the  object  activity.  The  argument  is  either  the  name  of  the 
object  activity  or  an  array  name. 


j will  on  return  to  the  calling  activity  contain  references  to  all  elements 
of  the  pending- table  that  concerns  the  object  activity.  These  references 
shall  give  all  necessary  information  for  the  occurrences  of  i in  the 
pending-table,  such  as  execution  time,  cycle  interval,  and  event  connection. 
The  argument  is  an  array  name.  The  specific  details  are  processor-defined. 
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SECTION  IV 

A REAL-TIME  FILE  SYSTEM  AND  JOB 
INITIALIZATION  ROUTINES  FOR  PROCESS 
CONTROL  COMPUTERS 


The  material  contained  herein  was  contributed  to  the 
Workshop  through  the  courtesy  of  Royal  Dutch  Shell  Petroleum, 
The  Netherlands.  It  was  presented  at  the  Fourth  Workshop 
on  Standardization  of  Industrial  Computer  Languages,  November 
1970,  by  Mr.  Antonius  M.  Hens,  and  published  in  the  Minutes 
of  that  Workshop,  pp.  234-277.  This  material  was  very 
helpful  to  the  Workshop  participants  in  their  discussions 


of  file  handling  procedures. 


A REAL  TIME  FILE  SYSTEM  AND  JOB  INITIALIZATION  ROUTINES 
FOR  PROCESS  CONTROL  COMPUTERS 

Contents 

1 . Real  time  file  system 

2.  Job  starting  and  completion  routines 

3.  Auxiliary  routines 

9 

4.  Figures. 
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1.  REAL  TIf'iE  l-ILE  SYSTEM 


1 . 1 Definitions  (F.ig.  1 ) 

/ 

1.1.1  A file  consists  of  a number  of  blocks  (NI1LK)  and  each 
block  of  the  file  contains  an  eoual  number  of  words 
(L3LK  = block  length).  This  length  is  to  be  equal  to  or 
an  integral  fraction  of  the  "record  length"  of  the  logi- 
cal unit  on  which  the  file  resides  (i.e.  1,  2,  3,  ^ , 6, 

8,  12,  etc.  but  not  5,  7,  9,  etc  if  this  record  length 

is  96).*)  if  it  » -to  be.  used.  x»  3«cTe*«.  a *00 tvs *oi>£  ***) 

The  total  number  of  words  in  a file  is  therefore  equal 
to  IJBLK  at  £BLK**). 

1.1.2  A file  is  specified  as  being  a member  of  a set  of 
files  belonging  to  a certain  unit.  Therefore,  NUKIT, 

[■'FILE  specifies  file  HFILE  of  unit  MUNIT.  Unit  numbers 
start  with  unit  0,  files  with  number  1.  Note  that  the 
files  UNiT  0 File  1 to  15  are  reserved  for  the  file  sys- 
tem itself. 

1.1.3  A file  is  always  processed  (read  or  written)  by 
block  rather  than  by  element.  Consequently,  to  use  a 
file  a block  pointer  (IPMT)  is  required. 


at)  96  is  the  number  of  words  of  a CDC  1700  disk  sector. 
Some  files  will  have  a "record  length"  which  is  equal 
to  L3LK  which  will  for  example  be  the  case  if  the  lo- 
gical unit  is  a card  reader,  line  printer,  typewriter, 
etc,  or  when  a special  bit  in  the  file  definitions 
block  is  set. 

In  the  case  of  a CDC  1700  computer  this  will  mean 
"word  addressable"  mode. 

xx ) An  exception  on  this  rule  are  files  located  on  in- 

or  output  devices  (line  printer  etc.).  In  such  a case 
NBLK  may  also  be  undefined. 

The  record  length  for  such  files  is  always  equal 
to i the  block  length  LBLK. 


loot'd.  OL4l<Af«.SS«*  loLa.  a-v-.o<4  «-  CX-W.V/  ^ <l~~ 
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1.1.4  files  may  be  res  id  on/  on  different  logical  units 
(i.e.  cere,  disc,  drum,  rate.  ) .*) 

Core  working  area  to  allow  the  use  of  files  which  are  not 
core  resident  has  to  be  specified  by  the  user  (1BUF  see 
section  1.2.2). 

1.1  .5  Each  file  has  a file  definition  block  (FDD)  which  in- 
dicates to  the  system  on  which  logical  unit  the  file 
reside:-  together  with  its  bitV/its 

block  size  and  number  of  blocks  and  whether  the  "rile  is 
in  a protected  or  unprotected  status  (see  section  1.2 
and  Fig.  1 ) . 

An  extra  protect  bit  to  prevent  accidental  and  erroneous 
deletion  of  files  (see  section  1.2.1)  is  included. KX' 

File  definition  blocks  of  so-called  rotate  files  have  part- 
ly the  same  specifications  as  above.  They  are  separately 
treated  in  section  1.1.7. 

1.1.6  To  use  a file  a block  pointer  (IPMT)  has  to  be  de- 
fined. The  block  pointer  consists  of  10  locations,  and 
has  to  be  defined  by  a dimension  statement  in  the  user's 
program,  e.g.  DIMENSION  IPltT  (10). 

Each  block  pointer-  is  unique  in  the  sense  that  in  a 
multiprogramming  real  time  system  the  block  pointer  is 
only  knovai  to  the  program  which  has  defined  it. 


x)  But  a particular  file  resides  only  on  one  particular 
logical  unit. 

xx)  Although  it  is  no  part  of  this  specification,  file 
definition  block  should  preferably  be  so  organized 
that : 

a.  they  can  be  resident  on  different  logical  units 
(core  drum,  or  d.isc^ Jtu ft 

b.  they  are  partly  core,  partly  drum  or  disc  resi- 
dent ; 

c.  that  spare  file  definition  blocks  can  be  reser- 
ved on  the  different  logical  units. 

In  selecting  the  possibilities  in  the  file  definition 
blocK  organization  it  is  essential  that  a high  flexi- 
bility is  not  obtained  at  the  expense  of  an  excessive 
consumption  of  core  space  and/or  execution  time. 


Av. e> oLa,  t saefor  «o 
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AMENDMENT 

to  BICM-CMP/4  MEMORANDUM  OF  DISCUSSION  No.  149/70), 
page  3,  point  9 

bit  15  R./W  controls  adjustment  of  1 and  2 

bit  1 A File  protect  bit  ex  FDB 

bit  13  Mode  (sector  or  word  addressable)  ex  FDB 

bit  12  Information  has  been  read  into  core  indicator 

bit  11  Flag  indicating  that  a writb  command  is  not  yet 

executed . 

tit  io  L ^ 


The  block  pointer  contains: 

1.  A self-relative  (core)  address  of  the  block  of  the 
file  to  which  this  pointer  is  pointing; 

2.  the  number  of  the  block  to  which  the  block  pointer  is 
pointing; 

3.  The  number  of  blocks  of  the  file  NBLK 

4.  The  number  of  words  of  each  block  LBLK 

5.  The  "file  address" 

6.  A pointer  to  the  file  protect  bit 

7.  The  number  of  the  first  in  core  block 

\ 

Q.  The  number  of  blocks  which  can  be  in  core;,  (in  the 
space  set  aside  for  the  file  in  IBUF) 

3.  the  file  logical  unit  number,  together  with  the  fol- 
lowing four  control  bits: 

bit  15  R/l?  indication  to  control  the  adjustment 
of  1 and  2*/ 


bit  14 


bit  13 


bit  12 


of  1 and  2*) 

indicator  whether  information  in  core 
is  originally  been  read  in  from  the  file[ 
attached  to  the  block  pointer 

flag  indicating  that  a write  command  is 
still  not  yet  executed 

"'ford  addressable  mode".  ^ 


10.  the  address  of  the  error  exit  in  the  user's  programme 
(section  1.2.2).  Upon  errors  it  is  left  to  the  user 
to  decide  which  actions  he  will  take.  If  no  address 
is  specified  the  testing  of  an  error  rill  result 
:i.u  a fatal  massage  and  stopping  of  the  job. 

x)  TV*  adjustment  of  the  block,  pointer  is  dependent  on 
the  previous  operations  performed  ( "read" / "write" 
and  or  "attach"  operations).  ' 

4 -cLi*  oJUouM  ^ A.  J-rCl-u*—  4-j  r\~ 

3 pwT  C-1  *0 
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1.1.7  A number  of  Tiles,  each  with  the  same  number  of 
blocks  and  of  eaual  block  length,  may  be  arranged  into 
a ‘'rotating1'  or  cyclic  file  (Fig.  2).  The  file  defini- 
tion block  of  a "rotating"  file  gives  the  system  infor- 
mation about  the  starting  address  of  the  set  of  files, 
the  number  of  files,  the  space  (o.g.  number  of  sectors) 
occupied  by  one  file  and  a pointer  to  the  current  file 
in  addition  to  the  normal  information  (see  section  1.1.5) 
contained  in  the  definition  blocks. The  file  definition 
block  of  a rotate  file  occupies  therefore  the  double 
amount  of  space  (6  words.)  as  the  regular  file  definition 
blocks  and  uses  therefore  two  file  numbers. 

Two  special  routines  are  provided  which  attaches  one  of 
the  files  from  such  a "rotating"  file  to  a block  pointer. 

The  second  half  of  the  file  definition  block  of  a rotate 
file  may  be  regarded  as  a regular  file  definition  block 
of  a so-called  "slave"  fife.  This  "slave"  file  definition 
block  has  always  the  "current"  file  in  its  file  address. 

The  "slave"  file  may  therefore  be  used  as  if  it  were 
a normal  file  (see  section  1.2.9). 

1 . 2 File  handling  routines 

1.2.1  Call_Define_{lWNITi_WFILEi_WDLKi_LBLKi_LUi_INpJ  ^ 

The  Define  and  Delete  routines  will  allow  the  dynamic 
generation  or  deletion  of  files; 

NUNIT  unit  number  of  the  reciuired  file 

NFILE  file  number,  if  this  file  number  is  equal  to  zero  on 
entry,  the  routine  will  return  a file  number  to 
the  user;  if  NFILE  is  not  equal  to  zero,  the  spe- 
cified file  will  be  defined  (see  also  IND). 

I’DLK  number  of  blocks  of  the  file 

LBLK  block  length 


LU 


logical  unit  number  e.g.  0 = core,  1 = drum,  * v-\ 
2 = disc,  etc.  C*-^-  ^rv. ^ 


IND  - 0 no  error  detected , file  is  defined  .€*****  /-a*,  ek****.  : 

attempt  made*  to  redefine  an  existing  file 
5 no  spare  available  on  requested  LU 
Xno  file  definition  block  available 
9 NFILE  out  of  range 

5 NUNIT  out  of  range  . 

* au  carmi  M<r?f«<e.s  r*>  n Trie 

CKffcwe  ocro/71  Jnvn  ro~T*s»i  Wi  «oA  /V  W/W  /VU 

M«y  v/66*  AS  F^C rr°Ajs  . ru  th»t  c**e  » •evrrnnv. 

w,ll  io^the  vneue  +F  JNb. 

t>»Me  *s  x (^Detnve  C - — > — «?«- 

Out.'/  if  Tvie  o«r tone  is  TL.e«t»  ^k- 

*-$l\  LU  — o "^0  LtrtM  nJiutAAf*  Co^€__  , p‘*r*  t-0q.ee.rs 

' -pUi* €_  o-  jflt 

C.&C-.  ifyoAu,  <■«■« s-LTt.  . 
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Note : it- ib-Zo  bo  conoidored  -to  plo&o  An  extra  protect 

bit  •'in  the  file  definition  block  in  order  to  prevent 
accidental  and  erroneous  deletion  of  files  (e.g. 
fixed  files  belonging  to  a particular  system.  This  pro- 
tect bit  is  then  to  be  set  by  a special  initiali- 
zation routine  *)). 

1.2.2  S^LL_ATTACH_^NUWITi_NFILEJ,  ^IPNTa_IBUFa_LENGTHaJERRXIT_} 

Attaches  file  NUNIT,  NFILE,*1*)  to  block  pointer  IPNT. 

The  block  pointer  is  10  locations  and  has  to  be  defined 

in  the  user's  program  by  a dimension  statement  as: 

DIMENSION  IPNT  (10). 

IBUF  gives  to  the  routine  the  address  of  file  work  area 
(for  non-core  files.).  The  dimension  of  IBUF  should 
(again  only  for  non-core  files)  be  sufficient  large 
to  contain  a complete  disk  sector,  or  a complete 
block  (LBLIC)  in  case  of  word  addressable  mode. 

It  should  be  considered  whether  the  use  of  an 
external  IBUF  may  be  advantageous. 


LENGTH 

TERRXIT 


specifies  the  number  of  words  in  IBUF 

gives  the  address  'in  the  user  program  to  which  ■ 
control  is  transferred  in  the  case  of  a read, 
write  or  other  possible  fatal  errors.  The  address 
in  the  argument  is  set  by  an 
ASSIGN  XXX  T03ERRXIT 
statement . 

If  the  argument  is  not  used  (i.e.  =0)  the  job 
will  come  to  a fatal  end  if  an  error  occurs  with 
a short  error  message.  Further  result  will  in 
such  a case  be  unpredictable. 


Upon  return  from  the  attach  routine  IPNT(1)  will  point 
to  the  first  block  of  the  file***iIPNT(2 ) will  contain 
a one  (1)  for  block  number  one;  IPNT(3)  and  (4)  contain 
the  number  of  blocks  and  the  block  length  (NBLK  and  LBLK) 
of  the  file.  See  for  the  contents  of  the  rest  of  IPNT 
the  description  given  in  section  1.1.6. 


x)  Such 


xx)  It  vail  advantageous  to  specify  NFILE  as  external. 

In  this  way  the  file  number  can  bo  assigned  at  system 
generation  time  without  the  need  of  rccompil ation s 
etc. 


a routine  can  be  m, 
PR0TFI.  (NUNIT,  NF1J 


ade  with  the  following  call : , 


*xx)more  accurate  IPNT(1)  is  pointing  to  tho  beginning 

of  the  core  work  area  IBUF  which  is  the  potential  lo- 
cation for  the  first  block  as  soon  as  it  will  be  made 
(or  road  in). 


No  W.  MAO*-  "t"  iCu-aS  Ut  &*o-t-oL 
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1.2.3  CALL_PR0T_EC_(IPI!T_) 
£^L-_yyi;{]^T_ilPNT] 


Those,  calls  put  the  file  to  which  IPNT  has  been  attached 
(see  1.2.2)  into  a protected/unprotected  status.  This 
Keans : 

when  a file  is  placed  in  a protected  status  no  other  pro- 
gram than  the  one  which  issued  the  protect,  is  able  to 
write  into  that  file  (sec  also  1.2.6  and  its  note). 

Note;  If  a file  is  already  protected  when  an  attempt  is 

made  to  protect  that  file,  the  program  which  requests 
this  protect  is  suspended  at  the  CALL  PR0TEC  state- 
ment until  a CALL  UNPR0T  (from  another  program) 
clears  the  protected  status  of  that  file.  Since 
this  situation  may  occur  with  more  than  two  pro- 
grams using  the  same  files,  queuing  of  the  sus- 
pended programs  is  required.  (This  will  mean  sa- 
ving of  all  registers,  the  priority,  etc.,  queuing 
according  priority  and  within  a priority  on  a 
first  in  first  out  basis). 

The  call  UNPR0T  routine  has  to  check  whether  any 
program  has  been  suspended  because  of  a call  PR0- 
TEC  for  that  particular  file  which  is  now  to  be 
unprotected.  If  there  is  such  a program  waiting 
on  the  queue  it  is  to  be  restarted  and  taken  of 
the  queue*). 

1.2.4  CALL_SEQRD_( IPNT] 

The  first  time  SEQRD  "sequence  read"  is  called  after 
attaching  the  file  to  IPNT  the  first  block  of  the  file  is 
read.  At  each  subsequent  call  the  next  block  is  read  in. 
Upon  return  IPNT  is  always  pointing  to  the  block  just  read. 
It  is  also  possible  to  use  SEQRD  after  a CALL  RANDRD 
(section  1.2.5).  Upon  exit  IPNT(1)  is  pointing  to  the 
block  just  read.  IPNT(2)  contains  the  block  number  of 
that  block. 


1.2.5  C A L L_ R AN URD_ ( I PUT x _ NBL0C K} 


"Random  read"  will  read  the  specified 
turns  the  block  pointer  IPNT  pointing 
of  the  file  attached  to  IPNT.  IPNT(2) 
value  of  NLSL0CK  at  return  from  random 
native,  the  name  RDJJLJC  (IPNT,  NUL0CK) 
be  used. 


block  NBL0CK  and  re- 
to  the  block  N3L0CK 
will  contain  the 
read.  As  an  alter- 
"rcad  block"  may 


x)  Note  that  in  the  queue  which  will  be  probably  a threaded 
list,  the  cells  ol  the  list  must  not  only  contain  the 
original  registers  and  priority  ancl  suspension  address, 
but  also  an  indicator  which  uniquely  indicates  for  which 
file  the-  program  has  been  suspended. 
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1.2.6  CALLUS  EOU R_  £ I PUT ± J RET U RH ^ 

C L hh..  lri^T  11 1 1 DJI] 

C £ LL_LKO^ND_  £ 1 l_’NTj 

£ALL_FlHVfll_(lPNT] 

After  a file  has  been  attached  to  IPNT,  blocks  of  the  file 
can  be  written  with  the  aid  of  the  above  routines.  The  file 
is  first  to  be  placed  in  a protected  status  by  a previous 
CALL  PR0TEC  (IPNT).  If  the  file  is  not  placed  in  a protect 
status  the  above  routines  will  issue  an  error  message  and 
return. to  the  error  exitlERRXIT  as  defined  in  section 
1.2.2*). 


The  first  time  SEOVR  or  URSTP  " sequence-write ::  or  "write- 
step"  is  called  after  attaching  the  file  to  IPNT  the  first 
block  of  the  file  is,  in  principle,  written**).  At  each 
subsequent  call  the  next  block  is  written.  Upon  return 
IPHT( 1 ) is  always  pointing  to  the  block  directly  after 
the  one  just  written.  IPNT(2)  contains  the  block  number 
of  that  block  to  v/hich  IPNT(1)  is  pointing. 

In  SEGUl  the  second  argument IRETURN  is  an  optional  return 
address  (set  by  an  assign  statement,  e.g.  ASSIGN  10  T0 
IRETURII)  to  which  control  is  given  as  long  as  the  end  of  -the  file 
has  not  yet  been  reached.  After  writing  the  last  block 
of  the  file  control  will  be  given  to  the  next  executable 
statement.  This  optional  return  offers  the  possibility 
of  performing  a so-called  D0-loop  over  an  entire  file. 


at)  Note;  Although  it  is  conceivable  that  another  program 
which  is  not  part  of  the  job  under  consideration, 
did  put  the  file  in  a protect  status,  it  is 
highly  unlikely  that  these  two  programs  will  al- 
ways run  in  the  same  time  slice  especially  be- 
cause each  program  will  have  to  pass  a test  phase 
during  which  the  other  program  is  probably  not  in 
operation.  Hence,  any  forgotten  CALL  PR0TEC  will 
already  during  testing  be  found  because  the  fatal 
error  message. 

xx ) "in  principle1'  because  of  efficiency  reasons  write 
commands  are  only  then  executed  when  a complete  core 
buffer  I13UF  is  fully  used, thus  making  space  for  a 
next  core  load,  or  when  file  processing  is  finished 
by  FINV/R  or  SEQEND. 
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The  CALL  SEOLND*)  will  be  used  to  end  sequential  file  pro- 
cedures (specially  file  write  procedures  SEQV'R,  \/RSTP)  in 
a correct  v/ay. 

Note:  that  il  the  SEQV'R  routine  is  used,  and  the  normal 

exit  has  been  reached  (end  of  the  so-called  D0  loop) 
a call  to  SLO.LND  will  be  regarded  as  a dummy  oper- 
ation and  may  therefore  be  omitted.  This  is  of  course 
also  true  for  VR3TP,  if  the  in  core  blocks  of  the  file 
were  truly  written  during  the  last  time  it  was  exe- 
cuted. 

FINVR  "filial  write"  is  a routine  very  similar  to  SSQEND 
but  vail  always  imply  a write  command.  A call  to  FINY'R 
has  therefore  the  exact  same  effect  as  a call  '!R3TP  di- 
rectly follov/ed  by  a call  SEQEND. 

Note:  All  the  above  routines  can  also  be  used  after  a 
previous  call  to  XANDRD  (IPNT,  NBLOCa) . 

.2.7  CALL  COPYFL  (NUNIT  1,  NFILE  1,  NUNIT  2,  NFILE  2, 

JLRRXIT) 

This  routine  copies  one  file  into  another**).  Note  that 
the  operation  of  copying  is  done  under  protection  of  the 
files  concerned,  which  again  may  result  in  job  suspen- 
sion and  oueuing  as  described  for  FR0TEC  and  UNPR0T 
(see  section  1.2.3). 

ERRXJX  contains  the  address  to  which  control  will  be  given 
if  a read/write  error  during  copying  occurs.  It  is  set 
by  an  ASSIGN  XXX  T0IERRXIT  statement. 

Note:  The  user  can  perform  his  own  copying  operations  by 
making  a duplicate  block  pointer  by  using  DUPIPT 
(see  section  1.2.10) 


x)  The  SEQEND  routine  is  required  because  a file  is  read 
or  written  per  block,  however,  if  a file  is  for  example 
disc  resident,  many  blocks  may  go  into  a sector.  The  true 
read  write  operation  to  or  from  disc  is,  however,  done 
sector-wise  in  order  to  economize  on  disc  transfers.  There- 
fore, this  special  routine  which  will  transfer  the  correct 
number  of  words  when  writing  is  stopped  somewhere  half- 
way the  file. 

xx)  A minimum  requirement  is  that  the  second  file  has  at 
least  the  same  number  oi  blocks  and  has  a block  length 
equal  to  the  block  length  of  the  first  file. 
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1.2.8  CALL  COPYCL  (NUMIT  1,  NFILE  1,  NUHIT  2,  NFILE  2, 

lEHRXITj 

This  routine  copies  file  NUNIT  1 , NFILE  1 into  file  NU- 
MIT 2,  MFILE  2. as  with  COPYFL  but  also  clears  file  NU- 
MIT 1,  NF1LL  1. 

The  operation  is  again  performed  under  protection  of  the 
files  as  is  described  in  1.2.7. 

Note:  It  may  seem  that  with  a separate  clear  file  route 
(e.g.  CLEARF)  all  needs  will  be  fulfilled.  The 
routine  described  here  could  then  be  made  by: 

CALL  COPYFL  ( ) 

CALL  CLEARF  ( ) 

but  this  will  mean  that  between  COPYFL  and  CLEARF 
tho  file  will  be  unprotected  (and  may  consequently 
be  updated  (and  protected)  by  another  program  (of 
higher  priority).  To  prevent  this  situation  the 
calls  have  to  be  combined  into  a call  COPYCL. 

Since  this  call  has  to  be  available  no  real  need 
exists  any  more  for  a clear  file  routine. 

1.2.9  r5^TATE__^NUNIT_t_rjFII;.EJL__  XPNTx_IBUFj L55?GTHjjERRXXT_2 

CALL.HISTgR^NUNIT^llFI^ 

IERRXIT^ 

These  routines  are  provided  to  communicate  with  so-called 
"rotating”  files  (see  section  1.1.7)*),  and  performs  the 
same  function  as  the  ATTACH  routine  (section  1.2.2). 


x)  A special  initializing  routine  (similar  to  DEFINE)  is 
required  to  initiate  tho  file  definition  blocks  of  the 
rotate  and  slave  file.  See  also  next  note. 


<K  C Lieut-  A*»-**X*Lu. 

c*u-  cuFJ-LB 

O-  tUAvJ-* 


IVS 
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CALL  R0TATL  will  attach  the  current  file,  to  which  the 
current  file  pointer  is  pointing,  to  the  block  pointer 
IPNT  and  increases  the  current  file  pointer  to  point  to 
the  next  file  in  the  rotating  of  cyclic  files.  At  the 
cane  time  the  file  address  in  the  second  part  of  the  file 
definition  block  will  be  set  to  the  address  of  this  ''next" 
file*}, 

CALL  HI5T0R  attaches  the  file  which  is  NDELAY  files  before 
the  file  to  which  the  current  file  pointer  is  pointing. 

The  current  file  pointer  is,  however,  not  changed.  (If 
NDELAY  = 0 is  used  the  same  file  out  of  the  rotating  files 
is  obtained  as  if  CALL  R0TATE  were  used,  but  without  read- 
justment of  the  current  file  pointer). 

NFILE  is  the  name  (number)  of  the  rotating  file. 

1.2.10  CALL_DUPIPT_^IPNTa_ JPNTjl_NUN1Ta_NF1LEJ[ 

makes  a duplicate  block  pointer  JPNT  from  block  pointer 
IPNT  (i.c.  pointing  to  the  same  work  area)  but  attached 
to  file  NUNIT,  NFILE.  Note  that  only  the  5th,  6th  and 
9th  location  of  the  block  pointer  JPNT  (see  section  1.1.6) 
are  obtained  from  the  special  file  definition  block  NUNIT, 
NFILE.  The  rest  is  a "copy"  of  the  block  pointer  IPNT, 
therefore  by  making  a call  ATTACH  for  NUNIT,  NFILE  and 
JPNT  but  using  the  same  buffer  IBUF  and  error  exit  ERRXIT 
does  not  necessary  give  the  same  result3^)* 

1.2.11  CALL_RE3IPT_XlPNT) 

Reset  IPNT  to  the  beginning  of  the  file  attached  to  it 
(i.e.  IPNT  (1)  points  relative  to  itself,  to  beginning 
of  work  area  IPNT  (2)  = 1). 

1 . 3 Using  the  File  Organization  Routines 

Considerable  care  should  be  taken  to  ensure  correct  use 
of  the  file  routines.  Any  misuse  may  lead  to  unrecoverable 
errors  and  program  stoppage. 


x)  As  mentioned  in  section  1.1.7  the  file  definition  block 
of  a rotate  file  is  equal  in  twice  the  number  of  words 
for  a regular  file  definition  block.  Because  of  the 
same  layout  the  second  half  may  be  used  as  the  file 
definition  block  of  a so-called  "slave"  file  with  file 
number  ociual  to  MFILE  i-  1 . Therefore  it  is  possible 
by  following  a call  R0TATE  by  a call  ATTACH  for  NFILE 
+ 1 to  obtain  two  block  pointers (IPNT  and  JPNT)  pointing 
to  two  files  in  the  rotating  files  which  are  next  to 
each  other,  (i.c.  at  completion  of  these  routines  the 
current  - 1 and  the  current  file). 

xx)  This  may  be  of  importance  .if  one  wonts  for  example  print 
a text  file  from  disk  on  the  line  printer.  One  makes  now 
a duplicate  block  printer  attached  to  the  "line  printer 
resident"  file,  but  with  the  number  of  blocks  NDLK  and 
bLock  length  LBLK  of  the  disc  resident  text  file.  By 
using  now  SE0R0  and  3L0WR  with  the  thus  obtained  block 

^ nf  or  'i  rnrrml  rnnnr'f  ( f i 1 r<  ^ now  nr'i  nf  r>r^  rp  if 
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i'otc-  that  on  a process  control  computer  one  can  have  se- 
veral jobs  (which  may  be  not  related  to  each  other)  where 
each  job  m;  y consist  of  a number  of  programs  (in  Fortran 
PROGRAM  statement)  or  overlays.  Each  program  may  use  se- 
veral subroutines.  Consequently  the  words  Job,  Program 
and  Subroutine  will  be  used  with  the  above  meaning. 

In  the  following  some  general  rules  are  given: 

1.3.1 

In  each  program  the  bock  pointers  used  should  be  dimen- 
sioned and  equivalanced,  e.g. : 

DII IEHSI0N  IPNT  (10) 

EQUIVALENCE  (IP,  IPNT  ( If ) ) 

Note  that  according  to  the  definitions,  IPNT  (1)  is  rela- 
tive to  itself. 

This  means  that  for  example 

IPNT  (IP) 

gives  (in  Fortran)  the  contents  of  the  first  element  of 
the  block  to  which  IPNT  is  pointing. 

IPNT  (IP  + 1 ) 

gives  the  contents  of  the  second  element,  etc. 

Very  often  it  is  possible  to  give  selfexplaining  names 
to  the  contents  of  a blook  such  as  high  limit,  low  limit 
desired  value  and  dead  band  for  a block  containing  alarm 
limits.  By  using  the  following  way  of  coding: 

DIMENSION  IALH  (10),  IBUF  (96) 

EQUIVALENCE  (HLIM,  IAL,  IALM  (1)),  (LLIM, IALM  (2)) 
EQUIVALENCE  (DESVAL,  IALM  (3)),  (DBAND,  IALM  (4)) 

INTEGER  HLIM,  DESVAL,  DBAND  , |V 

in  which  IALM  is  the  block  pointer  of  the  alarm  limits 
file,  the  values  of  the  alarm  limits  in  the  block  (after 
reading  a block  of  the  alarm  limit  file  by  one  of  the 
read  routinesdescribed  in  sections  1.2.4  and  1.2.5) 
can  be  found  in  the  locations: 

HLIM  (IAL)  for  the  high  limit 

LLIM  (IAL)  for  the  low  limit 

DESVAL  (IAL)  for  the  desired  value 

DBAND  (IAL)  for  the  dead  band. 

’•'hen  iloating  point  numbers  are  used  in  the  files  special  care 
has  to  bo  taken.  By  using  an  integer  variable  equivalenced  with 
a floating  name  problems  are  solved: 

EQUIVALENCE  (A,  1A)  (DIMENSION  IA  (2)) 

Then  I A - II  NT  (IP) 

1A(2)  = IPNT  ( IP  + 1)  gets  the  floating  point  figure  from 

the  file  into  A. 
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1.3.2  Use  11'  ns  argument  in  the  file  handling  routines  in- 
stead of  11 'NT  (e.g.  CALL  GEOilD  (Tl»)).  This  allows  the 
fortran  compiler  to  detect  that  the  subscript  IP  of  IPNT 
in  a following  statement  with  IPNT  (IP)  has  or  may  have 
been  changed.  Fortran  will  therefore  recalculate  the  in- 
dex and  will  not  assume  an  unaltered  index  IP. 

1.3.3  Before  using  a file  in  a program  first  attach  the  file 
to  a block  pointer  by  the  ATTACH  routine. 

1 . 4 Initialization  of  file  definition  blocks  (preliminary)  ~ 

A special  mass  storage  resident  program  i3  needed  which 
allows  the  initialization  of  the  ]fl4M>^file  definition 
blocks . 

This  program  can  probably  make  use  of  the  DEFINE  routine. 
The  program  will  read  in  file  definition  cards  of  the 
following  format: 

A2,  3 X,  715. 

The  cards  contain  according  to  the  above  format  following 
information: 

a.  for  a normal  file  v 

FL,  MUNIT,  NFILE,  NBLK,  LBLK,  LU y 

b.  for  a rotate  file 

ITUMIT,  HFILE,  NBLK,  LBLK,  LU,  NOFILES,  J e X^R. 
where 


NOFILES 


- logical  unit  of  file  (incl.  ripcord-  length 

bit^  l-e.  33.  FoA  ieooft 

= number  of  files  = 0 for  non-rotate  files. 


Special  control  cards  will  allow  the  optimization  of  the 
location  within  a certain  logical  unit  of  the  files  for 
example : 

NC  start  following  file  cards  for  the  disc  on  a new  disc 
cylinder.  I ■ 1 'j1  I • | j • ' ■ : • 

I 

The  Format  for  this  card  may  be  A2,  ;3X,  15  and  contains 
NC,  LU 

where  LU  is  again  the  logical  unit. 
ft  •'  W<Ui  *-  ^ 

U a.  <lurv>/vv-.W  7 IcXTP-  «Lb<7toS  T-f*.  AtS4Vi/«.^U^  <T§— 

iOA— Jbtc[xO^  yU&tkS  S A.A4tfiAUfi-)  \OA*A+Aa.  & W, 

-U.u-  Usf.Ltt-U  <n>  ”o~ 


-111- 


2.  JOD  STARTING  AND  COMPLETION  ROUTINES 

2 . 1 Genera i.x) 

Each  program  (separate  overlay)  of  a job  has  an  entry  in 
the  system  directory.  It  is  this  entry  which  is  threaded 
into  the  schedule  stack  when  a schedule  request  is  issued. 

recause  of  the  above  a program  cannot  be  rescheduled  again 
until  the  first  schedule  has  been  honoured  (program  taken 
into  execution). 

If  rescheduling  is  tried  when  the  first  schedule  is  still 
in  the  schedule  stack  the  request  is  rejected  and  control 
returned  with  the  Q register  set  negative. 

One  other  important  facet  of  rescheduling  a program  is  that 
the  program  has  to  be  re-entrant**) . However,  this  re- 
quirement cannot  be  met  for  most  of  the  jobs.  It  is  there- 
fore of  the  utmost  importance  that  a program  or  job  is  not 
rescheduled  (taken  into  execution  again)  before  the  pro- 
gram has  terminated  a previous  execution. 

The  above  two  facets  are  the  reason  for  providing  special 
(re-entrant)  subroutines  which  are  to  be  used  to  start  and 
to  terminate  a job.  An  additional  feature  of  these  sub- 
routines is  that  jobs  which  require  disc  transfers  can  be 
put  .into  a delay  status  in  order  to  provide  for  disc 
maintenance  time  (O-oO  min. ) without  the  loss  of  perti- 
nent information. 

2 . 2 C A L L_  I j j I T J ^ N ANE A _ I A RG z _ I N D_) 

C ALL_  3 TRT  J N AMEZ  _IAHO±_THD) 

^I'L_ENpj^2_^NAnEA__IJAIN) 

v.'here . 

NAME  is  the  name  of  the  job.  Name  is  to  be  defined  as 
external : EXTERNAL  NAME 

IARG  is  the  name  of  a dimensioned  array  which  contains 
the  input  arguments  (if  any),  for  the  job.  If  no 
input  arguments  are  required  a zero  (0)  is  to  be 
used. 


r.)  Although  it  may  scorn  that  these  remarks  apply  only 
to  a CDC  1700  computer  similar  observations  will  apply 
to  most  process  control  computers. 

xx)  At  least  when  it  is  a core  resident  program. 
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IND  ..a  a.,  error  indicator 

- 0 no  error 

- 1 no  root  available  to  store  arguments 

negative  request  to  start  job  rejected  (fatal 
error) . 

MAIN  is  the*  name  of  the  program  which  issues  the  call  to 
uJBJOw.  This  name  (i’lAIil)  is  used  to  release  cere  of 
this  program  part  (Note  that  a job  may  consist  of  more 
than  one  consecutive  program). $0 

INITJ'J  and  STRTJ3  are  almost  the  same  routines.  The  only 
difference  is  that  that  if  INITJO  does  not  accept  the 
arguments  because  the  table  of  arguments  for  that  job  1:: 
already  full  (IliD  = 1)  3TRTJB  can  still  accept  one  sot  of 
o ^guraent  s . 

The  arguments  are  stored  in  cells  of  a cylindrical  li-o, 
the  length  of  the  list  determines  how  many  sets  of  argu- 
ments can  bo  accomodated  (the  list  has  one  spare  cell 
which  may  be  used  by  STRTJB). 

2 . 3 Job  tables 

In  order  to  be  able  to  use  the  calls  as  described  in  2,1 
and  to  incorporate  other  features  such  as  the  automatic 
starting  of  jobs  at  n predetermined  time  interval  etc.  a 
special  program  which  should  be  under  the  responsibility 
of  the  system  supervisor  of  a particular  installation  is  re- 
quired and  which  can  be  called  :;Job  tables1'  (JBTAD). 

All  the  NAi-ib  arguments  of  the  previous  section  (2.1)  'which 
are  the  names  of  all  the  real  time  jobs,  should  be  entry 
points  in  this  JBTAI5  program. 

For  each  job  in  this  job  table  program  the  following  in- 
formation is  to  be  available;, 


1.  The  (initial)  priority  of  the  job. 

2.  V'hether  the  job  is  to  be  restarted  when  a second  etc,, 
call  is  made  for  the  job  while  it  is  still  busy  with  a 
previous  call. 

3.  '"hether  the  job  may  be  placed  in  a delay  status  for  disc 
maintenance . 


4.  V'hether  e special  job  (so-called  repeat  job)  is  to  be 
started  when  a secondary,  third,  etc.,  call  is  made  for 
the  job  which  is  still  in  execution  (see  also  under 
point  2 ) . 


5.  hether  the  job  is  to  be  started  at 
time  interval  by  a ;,clock,;  routine, 
job  must  have  a count-down  location 
of  the  required  time  interval. 


*) 
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C.  Per  a job  with  arguments  the  arguments  must  be  saved 
in  a cylindrical  list  (per  job)  on  a first  in  first  out 
basis.  A special  routine  is  required  for  these  jobs  to 
obtain  access  to.  these  arguments  (see  section  2.3). 

U CALL . ArtG_ ( NAME* _ 1 NHC ) 

Jobs  started  with  one  of  the  calls  given  in  section  2.1 
end  which  use  arguments  must  have  the  means  to  get  the 
value  of  these  arguments  from  the  cylindrical  table  (see 
section  2.2)  in  which  they  are  stored. 

For  this  purpose  the  JOBARG  routine  has  been  provided.  The 
routine  may  be  used  repeatedly  in  the  same  program  or  set 
of  programs  of  a -job.  An  example  is; 

DIMENSION  INHC  ( 1 ) 

EQUIVALENCE  (INH,  INHC  (1)) 

■ EXTERNAL  NAME  (name  of  the  job) 

.CALL  J 03 ARC  (NAME,  INH) 

ai-ur  execution  of  the  above  call 

INHC  (Ii'IH)  contains  the  first  argument  ( IARG  (1)) 

INHC  (INH  + 1)  contains  the  second  argument  etc. 
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3.  AUXILIARY  ROUTINES 

3. 1 CALl_MASK 

CALL  DMASK 


These  are  two  special  routines  which,  although  used  in  the 
file  organization  routines  themselves,  do  not  belong  to 
the  file  system  proper. 


The  routines  make  it  possible  to  use  non-re-entrant  non- 
inhibitod  Fortran  callable  routines  in  a multi-programming 
environment  by  first  making  a call  to  MACK  and  after  the 
routine  a call  to  OIIAGK.  The  routine  or  routines  called 
betv/cen  these  two  statements  should,  however,  in  no  case 
make  any  I/O  (input/output)  command  or  request. 

It  is  important  that  no  call  to  one  of  the  file  organiza- 
tion routines  is  made  if  a CALL  MASK  is  still  effective. 


3.2  C A LL_ L^C AL_ ( NAMEZ _ I BUFZ _ I ARC __ _1 


This  routine  ;'loads  on  call1''  the  subroutine  NAME  into  work 
area  1TUF. 

The  number  of  arguments  (IARG)  of  the  subprogram  must  match 
with  the  number  of  IARGs  in  the  call  LOCAL. 

The  effect  for  the  user  is  therefore  the  same  as  if  he  used 

CALL  NAME  ( IARG  1 XARGn ) 


The  work  area  IBUF  should  be  at  least  equal  to  the  length 
of  the  subprogram. 

Note;  NAME  will  most  likely  be  a core  resident  array  of  two 
locations  containing  the  address  of  the  subprogram 
on  disc  and  the  program  length.  Therefore  name  has 
to  bo  specified  as  external.  A special  program  may 
put  the  address  and  length  information  in  the  array 
after  the  subprogram  itself  has  been  placed  as  a 
file  on  mass  memory  storage. 


RL 


Wove 
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SECTION  V 


FORMAT  DEFINED  LANGUAGES 


At  the  First  Workshop  on  Standardization  of  Industrial 
Computer  Languages  the  Problem-Oriented  Languages  Committee 
was  first  organized  as  the  Fill-in-the-Blanks  Languages 
Committee  from  the  popular  format  for  such  languages  at  that 
time.  They  recommended  a name  change  to  Format  Defined 
Languages  Committee  and  eventually  to  Problem-Oriented 
Languages  Committee.  This  first  document  is  their  first 
requirements  and  definitions  report.  It  was  published  in 
the  Minutes  of  that  Workshop  as  Insert  VII,  pp.  53-57. 


■ 
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FORMAT  DEFINED  LANGUAGES 


EXPLANATIONS 

1.  DIGITAL  COMPUTER  OUTPUT: 

a.  Direct  digital  control  (DDC)  is  a means  of  imple- 
menting a control  function  by  direct  action  to  the  actuator. 

b.  Digital  setpoint  control  (DSC)  is  a means  of  imple- 
menting a control  function  by  setting  the  set  point 

of  an  external  controller. 

2.  DIGITAL  COMPUTER  INTERNAL  CALCULATIONS  AND  CONTROL 
FUNCTIONS 

a.  Regulatory  digital  control  (RDC)  uses  a large  group 
of  control  functions  short  of  optimization  which  may 

be  implemented  by  cascade  adjustment  of  set  points 
(DSC)  or  direct  action  to  the  actuator  (DDC).  This 
includes  sequential  control  as  well  as  the  usual  closed 
loop,  feedward  and  other  algorithms  irrespective  of 
time  scale  for  repetitive  actions. 

b.  Optimizing  control  is  a control  method  using 
special  calculating  procedures  aimed  at  arriving  at 
optimum  set  point  positions  for  regulatory  loops  to 
meet  a specific  operating  objective. 

FPL  IS  RECOMMENDED  IN  THESE  APPLICATION  AREAS 

1.  Data  Acquisition  by  Schedule  and  Interrupt 

2.  Data  Conditioning 

3.  Alarm  Log  and  Emergency  Response 

4.  Regulatory  Digital  Control 

5.  Support  of  Man/machine  Interface 

6.  Data  Storage  and  Retrieval 

7.  Communication  with  Other  Computers 
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C.  GENERAL  REQUIREMENTS  FOR  FPL 

1.  Process  Definition 

2.  On-line  Program  Expansion  and  Modification. 

3.  Should  make  maximum  use  of  industrial  terminology. 

4.  The  language  should  be  self -documenting.  The  source 
information  after  being  prepared  or  listed  should  be 
intelligible  to  the  application  engineer. 

5.  Must  interface  with  procedural  languages. 

6.  The  application  engineer  working  with  FDL  should 
definitely  not  have  to  concern  himself  with  bits, 
bytes  or  internal  number  representations,  about  the 
real  time  operating  system,  about  internal  interrupt 
responses,  or  about  routine  internal  file  handling. 

7.  Sufficient  iiagnostics  should  be  included  to  show 
improper  use  of  the  language. 

8.  Should  include  methods  for  the  definition  of  recovery 
procedures  to  insure  appropriate  operation  in  the 
event  of  system  failure. 

9.  The  method  used  to  identify  and  name  system  equipment 
should  be  such  that  names  and  addresses  need  not  be 
defined  more  than  once. 

10.  Information  named  within  this  language  should  be 
externally  accessible  by  references  to  said  names. 

11.  The  capability  should  be  provided  for  an  experienced 
programmer  to  add  new  format  definitions  to  the 
language. 

12.  Retrieval  and  documentation  of  the  information  after 
it  has  been  used  and  modified  should  be  possible. 

D.  SPECIFIC  ITEMS  IN  FDL 

To  be  specified  at  subsequent  meetings.  Example  items 

that  may  be  considered  are  attached. 
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EXAMPLES  OF  SPECIFIC  ITEMS  TO  CONSIDER  IN  FPL 

I.  Inputs-Scheduled 

A.  Analog 

1.  Indentif ication 

2.  Scanning  Rate 

B.  Pulse 

II.  Inputs -Interrupt 

A.  Analog 

B.  Contact  Closure 

III.  Inputs-Generated 

A.  Timers 

B.  Computed  Variables 

IV.  Alarm  and  Log 

A.  Analog  Inputs 

B.  Contacts 

C.  Computed  Variables 

V.  Conversion  of  Data  & Data  Processing 

A.  Eng.  Units 

B.  Aver.,  Delta,  etc. 

VI.  Control  Functions 

A.  Build  Loops 

B.  Build  Feed  Forward  & Interacting  Systems 

C.  Control  Calculations  with  Constraints 

1.  DDC 

2.  Set  Point  (Links  to  Variety  of  Calc.  Methods) 
J>.  Sequencing 

VII.  Control  Output 

A.  Analog 

B.  Contacts 

C.  Pulse 


-146- 


VIII.  Communications-External 

A.  Oper  Console-Pertinent  Variable  & Control  Info.  & Adjust 

B.  Engineer 

C.  Report  Writing-Typers  & Line  Printers 

D.  Other  Machines 

E.  CRT  Displays 

F.  Data  Storage  and  Retrieval 
IV.  Communications-Internal 

A.  Links  to  FORTRAN  Subr. 

B.  Background  Work  (Time  Share) 

X.  Misc.  Services  Routines  & Features 

I 
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RECOMMENDATIONS  FOR  FUTURE  ACTION 

In  order  to  conform  to  the  adopted  goals  of  the  Workshop 
and  to  further  develop  the  use  of  a "Format  Defined 
Language"  which  specifies  parameters  and  control  actions, 
a committee  is  to  be  formed  which  is  directed  to  do  the 
following: 

1.  Recommend  a generic  home  for  the  language(s). 

2.  Prepare  a more  complete  and  detailed  set  of  require- 
ments and  features  for  the  language(s). 

3.  Examine  the  relationship  of  these  requirements  and 
features  to  the  effectiveness  of  the  existing  languages 
of  this  type  and  identify  new  directions  for  development. 

4.  Recommend  preparation  of  a standard  language(s)  if 
and  when  this  appears  feasible. 


SECTION  VI 


PRELIMINARY  REQUIREMENTS 
PROBLEM-ORIENTED  LANGUAGES 


The  following  three  documents  present  the  work  of  the 
Problem-Oriented  Languages  Committee  in  developing  a set 
of  specification  requirements  for  a problem-oriented  language. 
This  work  is  not  yet  completed  since  the  Committee  has  con- 
centrated recently  on  its  development  of  a translator  system 
for  these  languages  (Avenue  2 of  the  discussion  in  the  Intro- 
duction) . "The  Preliminary  Requirements"  appeared  in  the 
Minutes  of  the  Second  Workshop  on  Standardization  of  Indust- 
rial Computer  Languages  on  pp . 51.63.  "The  User  Criteria  for 
Process  Oriented  Source  Languages"  appeared  in  the  Minutes 
of  the  Third  Workshop  on  Standardization  of  Industrial  Computer 
Languages  on  pp.  73-90.  The  "Pre-.liminary  Recommended  Speci- 
fication and  Procedure  for  a Process  Oriented  Language",  appeared 
in  the  Minutes  of  the  Fourth  Workshop  on  the  Standardization 
of  Industrial  Computer  Languages , pp.  88-101..  The  "Working 
Document  for  the  Specification  of  a Problem  Oriented  Language" 
appeared  in  the  Minutes  of  the  Fifth  Workshop  on  Standardiza- 


tion of  Industrial  Computer  Languages  on  pp.  137-179. 
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PRELIMINARY  REQUIREMENTS 
PROCESS  ORIENTED  LANGUAGES 


1.0  Introduction 

The  process  oriented  language  concerns  itself  with 
those  aspects  of  industrial  computer  systems  which  can  be 
jointly  expressed  in  the  following  source  documents 
(c.f . Section  2.0) : 

1.  Process  scheme  and  specification 

2.  Control  diagram 

3.  Logic  flow  chart. 

The  process  oriented  language  is  a set  of  rules  and 
symbols  which  are  understandable  by  humans  and  mechanies. 
It  expresses  information  contained  in  the  above  three 
documents  in  such  a form  that  it  can  be  translated  auto- 
matically into  working  computer  programs  and/or  data  used 
by  computer  programs. 

The  elements  of  the  language  are  identifiers  and 
operators.  Identifiers  (e.g.  names,  addresses,  etc.) 
designate  objects  and  attributes  of  objects.  Operators 
(e.g.  imperative  verbs,  arithmetic  operators,  etc.) 
designate  operation  to  be  performed  on  objects. 

These  concepts  will  be  more  rigorously  defined 


bel ow. 
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2 . 0 Source  Documents 

2.1  Process  Scheme  and  Specification 

To  describe  the  process,  we  consider  it  necessary 
to  provide: 

1.  P & I Diagrams 

2.  Tabular  lists  of: 

a)  Analog  inputs 

b)  Output  signals 

c)  Contact  signals 


The  tabulations  include  such  items  (but  are  not 
limited  to)  the  following: 

Analog  Inputs 

Identification  (name,  etc.) 

Value,  alarm  limits,  etc. 

Sensor  and  Signal,  etc. 

Sampling 

Conversion  to  engineering  units 
Notes 

Output  Signals 

Identification 
Device  and  signal 
Ciamps  and  alarms 
Feedback  characteristics 


Contact  Signals 

Identification 

Device 

Contact  rating 
Position  (open,  closed) 

Sampling  (random,  synchronous) 

2.2  Control  Diagram 

The  control  system  is  defined  by  a block  diagram 
similar  to  analog  computer  or  instrument  diagrams,  using 
existing  standard  symbol  sets  as  much  as  possible.  The 
diagram  consists  of  blocks  or  special  symbols  representing 
computations  performed  nearly  simultaneously,  and  connec- 
tions which  represent  the  flow  of  information  from  one 
computation  to  the  other.  The  calculations  include,  but 
are  not  limited  to,  two  term  controllers,  dynamic  compensa- 
tors, multipliers,  etc.  which  exist  in  the  analog  world 
or  which  would  exist  there  if  they  were  practical  (dead 
times).  Each  calculation  would  have  a number  of  parts  or 
connections  (an  exception  has  been  suggested  for  the 
equivalent  of  an  analog  controller),  and  might  have  actions 
relating  to  display  or  other  system  functions  in  addition 
to  the  control  (such  as  lighting  an  alarm  light). 

An  alternative  to  this  analog  tradition  already 
exists.  This  is  in  the  "loop"  concept,  that  exists  in  the 
many  systems,  where  measurement  value,  control  parameters, 
and  control  structure  information  are  conceptualized  in 
blocks  together.  While  this  point  of  view  might  be 
accommodated  in  the  approach  we  are  taking  here,  we  feel 
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that  a major  reason  for  not  doing  so  is  related  to  the 
need  for  effective  operator  interface  to  the  control 
system.  The  result  is  a specification  for  digital  control 
techniques  oriented  about  the  analog  tradition.  We 
believe  that  operator  interfacing  is  sufficiently  important 
and  detailed  to  require  separate  specifications  and  we 
question  whether,  as  a standard,  tieing  control  and  dis- 
play together  can  be  made  sufficiently  flexible  and  general 
to  satisfy  most  users. 

From  the  original  analog  point  of  view  a control 
system  is  defined  by  a block  diagram  and  a list  of  para- 
meters. For  purposes  of  discussion  the  control  system 
is  described  in  terms  of  the  following  entities  : 

A control  system  is  an  entity  with  a name  and  a 
series  of  control  elements. 

A control  element  is  the  digital  equivalent  of  an 
analog  computing  block.  It  is  an  entity  with  a 
name,  a type  (controller,  multiplier,  calculation, 
etc.)  and  several  variables  associated  with  inputs, 
outputs,  and  parameters  which  may  be  used  as  an 
input  to  another  calculation. 

A variable  is  an  entity  having  name,  arithmetic 
type,  engineering  units,  data  entry  information 
(whether  the  value  is  calculated,  entered  manually 
or  entered  from  the  supervisor). 

A macro  element  is  an  element  whose  computation 
is  defined  in  terms  of  other  elements  (effectively 
in  a diagram)  but  which  is  treated  in  other 
respects  like  a control  element.  We  assume  the 
capability  to  define  macro  elements  out  of  other 
elements  or  as  computational  procedures. 
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By  the  way  of  illustrating  these  concepts,  a tabular 
representation  of  a series  of  control  elements  is  given 
in  Figure  1.  It  is  assumed  that  the  element  variables 
are  all  indicated  by  symbolic  references  and  that  any 
undefined  variables  can  later  be  specified  by  a table  of 
the  form  shown  in  Figure  2.  The  variable  references  are 
grouped  in  Figure  1 in  order  as  outputs , inputs  and 
parameters.  There  is  a single  main  output  which  is 
assigned  the  name  of  the  element  unless  otherwise  specified 
in  the  table  (although  there  are  calculated  values  to  be 
stored  with  the  element  which  are  not  explicit  in  the 
table  such  as  the  integration  in  a PID).  The  purpose  of 
the  table  is  to  show  the  nature  of  the  control  system 
specification.  While  this  might  appear  to  provide  a basis 
for  a fill  in  the  blanks  implementation,  it  is  not  our 
intent  to  describe  the  form  of  the  language. 

It  will  be  noticed  that  in  Figure  1 connections  are 


made  by  referring  to  common  variables  or  to  the  output  of 


a preceding  variable.  As  a matter  of  principle,  we  would 
prefer  free  bi-directional  interconnection  between  all 


variables  (including  any  stored  values)  intermediate  to 


final  results.  If  the  name  of  the  main  output  was  used 
as  the  name  of  the  main  variable,  subscripts  could  be 


used  to  access  secondary  variables. 
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Definition  of  entries  in  Figure  1 : 

FRC104  is  a PID  controller  with  1 sec  sample  time 
V103  is  its  valve  output 
F101  is  its  measurement  (a  flow) 

SP104  its  setpoint 

Initial  Status:  Auto-manual,  positional  - 

incremental,  increase-decrease,  etc. 

KP104  Proportional  gain 

KI104  Integral  gain 

KD104  Derivative  gain 

HL104  Hi  limits  to  valve  travel 

LL104  Lo  " 

CALC  No. 4 is  a multiplier  for 

F85,  a flow  measurement  and 

P85 , a pressure  measurement  giving  as  a result 
a compensated  flow. 

CALC  No.  5 is  a sample  and  hold  element  which 
picks  the  peaks  of  A33 , an  analyzer,  under 
logical  control  of  CMP10 , a comparator. 

The  variables  are  specified  in  terms  of  their  real 

or  logical  character,  their  conversion  properties, 

and  their  data  entry  (or  operator  interface)  propertie 

The  assignment  of  a name  and  type  to  a control  element  is 

a convenient  means  of  tabulation,  and  does  not  imply  any 

particular  method  of  language  implementation. 


. A 


CONTROL  ELEMENTS 
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2.3  Logic  Flow  Charts 

i 

It  is  proposed  that  the  process  be  delineated  by  the 
flow  charts.  The  flow  charts  completely  describe  the  pr  '‘ess 
logic  and  operations  to  be  performed  during  normal  operation, 
and  also  under  exceptional  or  emergency  conditions. 

Basically,  the  flow  charts  describe  how  the  equipment 
and  devices  specified  on  the  instrumentation  and  control  diagram 
are  manipulated  to  accomplish  the  required  actions. 

It  is  required  that  a system  have  a provision  to  initiate  1 

or  terminate  any  procedure  in  response  to  : 

a)  a random  external  event 

b)  a request  by  another  procedure 

c)  an  abnormal  condition  detected  within  a procedure 
during  execution. 

Conditions  for  initialization  and  termination  are  des- 
cribed  on  each  logic  flow  chart  and  thereby  describe  the  other  | 

procedures  or  events  in  the  system.  jj 

The  logic  flow  chart  consists  of  a group  of  operations 
represented  by  suitable  standard  symbols.  (Note:  Each  symbol 

and  its  contents  correspond  to  a single  language  statement.  ) 

The  symbols  are  connected  with  lines  and  labels,  so  that  the 
process  operation  is  completely  described. 

It  is  noted  that  six  (6)  standard  symbols  are  sufficient 
to  describe  any  process  sequence.  These  are  the  Query,  Action, 

Message,  Connection  Label,  Initiate,  and  Terminate  symbols. 


J 


expr 


and 


The  Query  symbol  is  represented  by 
and  has  the  following  meaning: 

If  expr  = TRUE  go  to  right,  otherwise  go  down.  The 
"expr"  may  be  any  relational  or  logical  expression.  For 
example,  "expr  may  be: 

FT1  ^.40,  AND  FTI  ^ 80 ; or  (Dll  AND  DI2 ) OR  DI3; 

where  FTI  is  a real  value  and  Dll,  2,  3 are  digital 

inputs . 

The  action  symbol  is  represented  by  — | 
means  any  unconditional  operation  by  the  system.  Examples 
of  such  unconditional  operations  are : 

a)  Evaluate  an  arithmetic  expression 

b)  Operate  an  external  analog  or  digital  hardware  device 

c ) Read  and  save  the  value  of  an  analog  input  device 

d)  Read  and  save  the  condition  of  a digital  input  device 

e ) Initiate  a conditional  or  unconditional  time  delay 

f)  Change  the  value  of  attributes  describing  an  analog 
input 

g)  Change  the  value  of  attributes  describing  a DDC 
algorithm 

h)  Execute  another  procedure 

The  Message  symbol  is  represented  by  — and 
means  the  unconditional  output  of  the  message  referenced  by  n. 


The  Connecting  Label  symbol  is 


©, 


where  n is  a numeric. 


alpha,  or  alpha  numeric  string  and  in  general  refers  to  another 


connecting  label  containing  n in  the  flow  chart  of  procedure. 


-160- 


The  Initiate  and  Terminate  symbols  are  0-  and  ~<1 
respectively,  and  represent  the  beginning  and  ending  of  a 
procedure. 

3.0  Man-Machine  Communication 

Man-machine  communication  utilizes  devices  such  as 
typers,  printers,  keyboards,  consoles,  and  CRT's. 

The  scope  of  the  Process  Oriented  Language  includes  the 
content  of  the  communication  between  man  and  machine,  but 
excludes  the  formats  of  the  messages  used  in  communication. 

4.0  Classification  of  Objects 

4. 1  Devices 

The  term  "device"  includes  such  things  as  process  actu- 
ators and  sensors,  control  loops,  or  even  complete  process 


units. 


A simple  device  is  one  which  is  not  composed  of  other 


devices , 


A composite  device  is  one  which  is  composed  of  other 
devices,  either  simple  or  composite. 

4.1.1  Attributes  of  Devices 

In  general,  devices  have  the  following  attributes: 

1.  Description  (name) 

2.  Components  (parts  list) 

3.  Variables 


i 


As  a specific  example,  a simple  external  device  such  as 
a valve,  has  the  following  attributes: 

1.  Description  (name) 

2.  I/O  elements  (latching  relay) 

3.  I/O  variable  (eg.  actual  and  desired  state) 

4.2  Variables 

A variable  is  any  arbitrary  data  structure. 

4.2.1  Attributes  of  Variables 

Example:  The  following  attributes  are  representative  of 

those  associated  with  an  analog  input  variable: 

Name 

Value  and  initial  value 

Process  Unit  ID 

Change  criteria 

Signal  properties 

Engineering  unit  conversion 

Filtering 

Sample  rates 

Alarm  limits 

Reasonableness 

Rate  of  Change  limits 

Deadband 

Priority  of  point 
Data  type 
Synchronization 
Data  compression 
Demand  read 
Miscellaneous 


V1  \ 

I 

I 

- 
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4.3  Procedures 

Procedures  such  as  programs  and  sub-programs  are  within 
the  scope  of  this  language. 

5.0  Classification  of  Operations 
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6.2  Shorthand  Form 
The  elements  of  the  language  occupy  fixed  relative 

character  positions  in  the  input  stream  and  are  not  separated 
by  delimiters.  In  this  form  the  language  resembles  a typical 
fill-in- the-blanks  language  such  as  PROSPRO  or  BICEPS. 

6. 3 Publication  Conventions 

The  process  of  preparing  this  specification  and  subse- 
quent user  manuals  for  printing  requires  a form  of  expression 
which  makes  the  reading  of  printed  text  easier.  It  is  there- 
fore necessary  to  define  conventions  to  be  used  when  describing 
the  language  in  publications. 
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USER  CRITERIA  FOR  PROCESS -ORIENTED 


SOURCE  LANGUAGE 


User  criteria  are  the  attributes  of  the  Program-oriented 
Language  (POL)  which  enable  the  user  to  define  his  process  to 
the  computer  system.  The  computer  system  is  represented  by 
(Figure  V-l)  a group  of  functional  processors  interconnecting 
through  a central  processor.  The  user  communicates  his  process 
requirements  to  these  processors  by  a combination  of  statements 
representable  in  Bachus  Normal  form  consisting  of  specification, 
sequences,  procedures  and  conditionals. 

Sequences  can  be  implemented  on  any  of  the  processors. 

They  consist  of  a string  of  sentences  initiated  by  a conditional 
which  is  implemented  through  the  Central  Processor  (CP).  The 
physical  process  which  can  be  a batch,  or  continuous  process  is 
implemented  with  sequences  in  the  respective  functional  processor 
and  initiated  at  system  start  up.  The  sequence  describing  the 
batch  process  are  grouped  in  a separate  Batch  Processor. 

The  attributes  of  the  following  processors  are  described 
below. 

1.  Analog  Input 

2.  Analog  Output 

3.  Digital  Input 

4-.  Digital  Output 

5.  DDC 

6.  Man-Machine  Communication 

7.  Computation,  Arithmetic  and  Logic 

8.  File  Builder 

9.  Batch  Processor 

10.  Cold  Start  and  Maintenance 

Those  attributes  of  the  functional  processor  which  are 


static  information  are  characterized  in  the  specification  state- 
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ments  and  the  dynamic  operations  which  act  on  the  specifica- 
tions are  characterized  in  the  procedure  statements. 

r 

i 

CHARACTERISTICS  COMMON  TO  ALL  MACHINES 

1.  A program  memory  and  a date  memory  (but  common  to  all 
machines ) 

2.  A program  counter  (all  machine  programming  languages  are 
assumed  to  be  sequential. ) 

3.  A repetition  stack  in  which  is  stored  a list  of  fre- 
quency code-address  pairs  indicating  that,  when  free, 
the  machine  will  jump  to  any  address  from  the  stack  in 
its  program  whose  time-f or-next  repetition  condition  has 
been  met. 

4.  Has  a terminate  command  TMT  which  releases  machine  to 
process  next  request. 

5.  Has  a repeat  command: 

RPT  freq  init . 

which  causes  the  frequency  code  to  be  placed  on  the  repe- 
tition stack  along  with  the  address  after  that  of  the  RPT 
command.  Also  has  a release  command:  RLS  address , which 

deletes  any  pair  with  the  given  address  from  the  repeti- 
tion stack. 

6.  A Time  marker  command: 

TM  address 


whose  function  is  to  increment  a time  marker  (see  coor- 
dinating machine)  and  to  release  processing  from  present 
program  if  the  time  marker  count  is  completed.  Also  sends 


MAN-MACHINE 


COMMUNICATION  PROCESS 


DIGITAL  OUTPUT 
(Boolean) 


Initiation 


T/S  ^ 

Batch  (Priority) j 


External 

Time  (Duration, clock) 
Internal 


w 

l 
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a return  address  to  the  coordinating  machine-time  marker 
stack. 

7.  A machine  request  stack  containing  addresses  to  be  jumped 
to  on  completion  of  any  present  program  and  a command  re- 
questing an  action  from  another  machine. 

RQST  machine  address 

This  command  places  the  indicated  program  memory  address 
on  the  request  stack  of  the  appropriate  machine. 

8.  In  the  interests  of  permitting  data  structure  definition 
and  manipulation  one  might  add  to  any  of  the  machines  with 
Load  and  Store  commands  any  of  the  following 

a.  Interchangeability  of  data  and  program  memory 

b.  An  indirect  address  bit 

c.  Increment  register  commands 

I NR  n Register  no  limit 

DCT  n Register  no  limit 

where  n is  the  amount  of  increment  and  limit  is  a value 
for  a skip  test,  skipping  the  next  instruction  if  the 
limit  is  reached. 

d.  With  reservation  we  might  add  a minimum  number  (5  or 
or  10  at  most)  arithmetic  commands  and  register  (add 
complement,  and  and/or)  and  skip  tests. 


COORDINATING  MACHINE 

1.  Has  a time  marker  stack  (Dijkstra  semaphore)  and  a com- 
mand, STM  n address,  (set  time  marker  stored  at  address 
to  count  n completed  conditions  before  release).  The 
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time  marker  stack  contains  marker  address  - machine-pro- 
gram  address  triplets  such  that,  when  free,  any  machine 
with  an  entry  in  the  stack  corresponding  to  a completed 
time  marker  will  be  returned  to  the  program  address. 

This  permits  a uniform  way  of  synchronizing  actions  with- 
out requiring  any  assumptions  about  who  triggers  what 
program. 


DDC  MACHINE 

1.  Has  a set  of  standard  numbered  registers  of  sufficient 
number.  Each  register  would  allow  standard  data  informa- 
tion storage  but  would  allow  an  "undefined"  code  as  well. 

2.  Has  a load  register  command: 

LD  Register  number  address 

3.  Has  a store  register  command: 

ST  Register  number  address 

4.  Has  a "de-defining"  command,  DED,  which  puts  all  registers 
in  an  undefined  state. 

5.  Has  an  algorithm  command: 

ALG  type 

whose  function  is  to  act  on  the  entire  set  of  registers 
as  a block  and  apply  to  these  an  action  appropriate  to 
the  type  code.  There  would  be  standard  algorithm  types 
such  as: 

Controller 

Lead  Lag 

Square  Root,  Adder,  Diffencer,  etc. 
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There  might  also  be  a "higher  level  language"  type  whose 
only  function  would  be  to  transmit  the  data  to  the  "higher 
level  language"  machine  along  with  a request  for  action  and 
a return  address.  The  action  would  then  terminate. 

As  an  example  of  the  function  of  this  machine  consider  the 
controller  algorithm.  A list  of  data  normally  dealt  with 
in  a controller  might  be  as  follows: 

1.  Error 

2 . Auto  manual  status 

3.  Manual  input 

4.  Valve  analog  feedback 

5.  Valve  too  low  digital  signal 

6.  Valve  too  high  digital  signal 

7.  Feed  forward 

8.  Proportional 

9.  Reset 

10.  Derivative 

11.  Derivative  filter  gain 

12.  Valve 

13.  A Valve 

14.  Derivative  Data 

15.  Integral  Data 

16 . Mode  Code 

Certain  (or  all)  of  these  data  forms  might  be  optional  in  which 
case  the  algorithm  would  recognize  any  undefined  registers  and 
act  accordingly  (Such  options  might  also  be  defined  explicitly 
in  a mode  code)  For  instance,  although  the  controller  in  its 
most  general  coding  is  three  term,  we  might  compile  a two  term 
controller  driving  a valve  into  code  as  follows: 


LD 

1 

ERROR 

LD 

2 

AM 

LD 

3 

MAN 

LD 

8 

PROP 

LD 

9 

RESET 

A LG 

CONTROLLER 

STA 

12 

VALVE 

RQST 

AO 

OUTVALVE 

TMT 

This  last  command  is  a request  to  the  analog  output  machine 
to  go  to  the  address  of  a routine  that  outputs  the  valve. 


ANALOG  INPUT 


1. 


2. 


3. 


Has  an  address,  a condition  register,  and  a device  addres 
register  plus  several  data  registers  with  loading  and 
storage  commands. 

LD  Register  no.  address 
ST  Register  no.  address 
Has  increment  and  decrement  register  commands 
INR  n register  no  limit 
DCR  n register  no  limit 
Has  input  c omman  d 
RAS  type 

(Read  analog  sensor)  where  the  type  code  would  cover 
standard  device  types  such  as  current  (or  voltage)  out, 
millivolts  out,  pulse  width  out,  etc.  and  where  the 


-172- 


address  register  is  where  data  is  stored;  the  device 
register  indicates  which  point  data  is  input  from. 

4.  Has  skip  commands 

SOF  n (skip  on  fault)  where  n is  the  bit  in  the 

condition  register 

5.  Has  filter  and  convert  commands  acting  on  data  in  regis- 
ters and  at  the  address  in  the  address  register 

FLT  type 
COW  type 

ANALOG  OUTPUT 

Same  as  analog  input  except  for  items  3 and  5. 

3.  Has  output  command 

OAV  type  (Output  Analog  Value) 

5.  Has  conversion  command 
CONV  type 

DIGITAL  INPUT 

Same  as  analog  input  except  for  items  3,5  and  it  has  a 
bit  field  register  for  defining  the  bit  read  into. 

3 . RDS  type 

(Read  digital  signal) 

5.  Masking  commands  and  extra  registers 

CMR  register  no  (compliment  register) 

AND  register  no  address 
OR  register  no  address 
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6.  Skip  commands: 

SKBS  n address(Skip  if  bit  n of  the  word  in  the 
address  is  set). 

DIGITAL  OUTPUT 
Same  as  above  with 
3.  ODV  type  Output  digital  value 

HIGHER  LEVEL  LANGUAGE  MACHINE 
Same  type  machine  with  higher  level  language  available. 

CONSOLE  MACHINE 

1.  The  machine  would  have  a keyboard  register  or  registers 
permanently  containing  a code  defining  the  "ored"  state 
of  itself  and  the  most  recent  keyboard  actions  on  a bit 
by  bit  or  field  by  field  basis. 

2.  It  would  have  a data  register  with  Load  and  Store  commands. 

3.  AND,  OR,  and  bit  skip  test  commands  as  in  Digital  Input 

4.  Display  commands 

a.  DSP  device 

Transmits  code  in  data  register  to  console  device 

b.  DS PC  char  x £ 

Positions  are  given  character  at  position  x,  y on  the 
scope 

c.  DSPVC  mode  x1  y-^  x2  y2 

Positions  a vector  of  given  mode  (solid,  dotted,  etc.) 
from  point  x^  y^  to  point  x^  y2  on  scope. 
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SOME  DEFINITIONS 


Backus  Notation 


A notation  used  to  describe  the  syntax  of  languages. 

The  notation  is  defined  below. 

1.0  Metalinguistic  Variable 

yp>  A sequence  of  characters  enclosed  by  the  bracket 
termed  a metalinguistic  variable. 

The  values  of  a metalinguistic  variable  are 
sequences  of  symbols. 

2 . 0 Metalinguistic  Connectives 

( I)  Explicit  Connectives 

: :=  ,rIS  defined  as" 

Example:  a ::=  ■ b • reads  as  " a - is  defined 


to  mean  b "mean  ■ b'  " 

"inclusive  or" 

Example:  a - / b * reads  as  " a •-  or  b " 

(2)  Implicit  Connective 

The  absence  of  an  explicit  connective  between  two 
metalinguistic  variables  implies  the  presence  of  the 
connective  "and". 

Example:  a b reads  as  - " a and.  b ". 

3.0  Metalinguistic  Constants 

Any  symbol  which  is  not  a variable  or  a connective 
is  termed  a constant  and  denotes  itself. 

Example:  The  string  of  symbols  JOE  is  a metalinguistic 

constant.  A permissible  synomum  of  metalin- 
guistic constant  is  literal.  Also,  literals 
may  be  optionally  underlined  for  easier  reading. 
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4.0  Syntax  Equations 

A syntax  equation  is  the  definition  of  a metalinguistic 
variable. 

Examples : 

(1)  <^.ettef>  : :=A/B/.  .../  i.e. 

"The  variable  letter  is  defined  as  one  character 
of  the  alphabet” . 

(2)  digits  : :=  0/1/2/3/4/5.  • • /9  i.e. 

// 

"A  digit  is  one  of  the  characters  0,1,2,  etc. 

(3)  <f alphanumeric  character^  : :=  </letter>/  ^digitA 

"An  alphanumeric  character  is  a letter  or  a digit" . 

(4)  ('integer^  : :=  ^digiO  / <^digit>  <' integer^ 

"An  integer  is  a digit,  or  digit  immediately  followed 
followed  by  an  integer" . 

5.0  Backus  Normal  Form  of  Language  Definitions 

The  set  of  syntax  equations  which  completely  define  the 
syntactic  rules  of  a language. 


FORM  OF  A PROGRAM  AND  SENTENCE 
^ PROGRAM  UNIT>  = <^TITEE  C PROGRAM  B0DY>  < END  > 

/ TITLE  > = <' HEADER  > <LIST  > 

/!T:ADER>  = SPECIFICATION /PROGRAM/SUBROUTINE/ 

REAL  FUNCTION/INTEGER  FUNCTION /LOGICAL  FUNCTION 
AM  B0DY>  SENTENCE^/ 

S SENTENCE  ' <J>R0GRAM  B0DY> 


CLAUSE  LIST  =.  CLAUSE  / CLAUSE  DELIMITER  • CLAUSE  LIST 

•■•CLAUSE  = ^SPECIFICATION  CLAUSE>  /<  DECLARATION  CLAUSE  •/ 
-'EXECUTABLE  CLAUSE 


END  ' = END.  SENTENCE  TERMINATOR, - 


Underfined  Productions: 

SENTENCE  TERMINATOR 

1 

DELIMITER  " 

DECLARATION  CLAUSE 
EXECUTABLE  CLAUSE 
SENTENCE  ID 


FORM  OF  A SPECIFICATION  CLAUSE 

, SPECIFICATION  CLAUSE  • = - IMPLICIT  SPECIFICATION  CLAUSE  / 

EXPLICIT  SPECIFICATION  CLAUSE 

EXPLICIT  SPECIFICATION  CLAUSE  - = CLAUSE  ID  DELIMITER 

. IMPLICIT  SPECIFICATION  CLAUSE 

IMPLICIT  SPECIFICATION  CLAUSE  = OBJECT  ID  DELIMITER 

DATA  LIST 

<"DATA  LIST>  = DATA  ITEM  ’ / ^ DATA  ITEM  DELIMITER  DATA  LIST. 
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'DATA  ITEM..'  = ■ "LIST  / DATA  TYPE  ID  DELIMITER  • LIST 

Undefined  Productions: 

CLAUSE  ID 
OBJECT  ID 
DATA  TYPE  ID 
DELIMITER 

FORM  OF  LIST  AND  NAME 

LIST  = LIST  OF  NAMES.-/-  LIST  OF  VALUES  >/ 

/LIST  OF  NAMES > <(DELIMITER>  <LIST>  / 

/LIST  OF  VALUES/’  /DELIMITER^  <LIST>  / 

LIST  OF  NAMES  = NAME  / NAME  DELIMITER  LIST  OF  NAMES 

NAME  = VARIABLE  NAME  - A DEVICE  NAME  > /-  PROGRAM  NAME  ' 

LIST  OF  VALUES  = NUMERIC  VARIABLE  / 

- LOGICAL  VARIABLE  / 

- NUMERIC  VARIABLE  • DELIMITER  -LIST  OF 

VALUES  " / 

LOGICAL  VARIABLE  • - DELIMITER  • - LIST  OF 

Undefined  Productions 
DELIMITER 
VARIABLE  NAME 
DEVICE  NAME 
PROGRAM  NAME 
LOGICAL  VARIABLE 


VALUES. 
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FORM  OF  VARIABLE  AND  ATTRIBUTE 


VARIABLE  ' = ATTRIBUTE  /.  ATTRIBUTE  - ■ END  OF  FIELD  VARIABL 


'ATTRIBUTE  ■ = • NUMERIC  VARIABLE  .’/ 
. LOGICAL  VARIABLE  •/ 


- CHARACTER  VARIABLE  ■ / 

-'NUMERIC  VARIABLE  ^ END  OF  FIELD  - VARIABLE  / 
LOGICAL  VARIABLE  - . END  OF  FIELD  - . VARIABLE  / 

- CHARACTER  VARIABLE  *•  END  OF  FIELD  VAR  TABLE 


NUMERIC  VARIABLE  • « REAL  V INTEGER 


Undefined  Productions: 


REAL 


INTEGER 


LOGICAL  VARIABLE 


END  OF  FIELD 


CHARACTER  VARIABLE 


EXAMPLE  OF  DESIGN  CRITERIA  FOR  FUNCTIONAL  PROCESSORS 


Specifications  (sensor  characteristics,  and  parameters) 

1.  Procedure  to  input  e.g.,  A/D  multiplexer,  address,  voltage 
scaling  information  etc. 

2.  Validation 

3.  Conversion  parameters 

4.  Filter  parameters 

5.  Alarm  limits 
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Procedures  (sensor  operation  and  data  processing) 

1.  Rate  of  scan 

2.  Base  time 

3.  Order 

4-.  Action  of  completion 

5.  Storage 

6.  Type  of  scan 

7.  Stop  scan 

8.  Options  e.g.,  filter,  alarm  checking,  etc. 

DIGITAL  INPUT  (Boolian) 

Specifications 

1.  Input  Address  (Control  Word) 

2.  Word  size,  bit  position 

3.  Initial  Conditions  or  Normal  State 

4.  Msgs.  (Normal,  Abnormal,  Changes) 

Procedure 

1.  Rate 

2.  Base  Time 

3.  Actions 

4.  Logical  expressions  of  interrelations  with  other  digital 
input 

DIGITAL  OUTPUT  (Boolian) 

Specifications 

1.  Output  Address 

2.  Word  size,  bit  position 

3.  Duration 

4.  Msgs,  (such  as  confirmations ) 
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Procedure 

1.  Rate 

2.  Base  Time 

DDC 

Specifications 

1.  Type 

2 . Input  ID 1 s 

3 . Output  ID 1 s 

4.  Parameters 

5.  Alarms  (No  control  alarm,  etc.) 

6.  Msgs  (Including  displays,  etc.) 

7.  Set  point 
Procedures 

1.  Rate 

2.  Base  Time 

3.  Set  point  changes 

MAN  MACHINE  COMMUNICATION  - OUTPUT 
Specifications 

1.  Device  Name  (Tel-type,  CRT,  Mag  Tape) 
Procedure 

1.  File  Name 

2.  File  Description  (e.g.  Floating  pt.  etc.) 

3.  Format  (including  graphs) 

FILE  BUILDER 


Specifications 
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GLOSSARY 


B 


! 


Semaphore 


A counter  mechanism  for  coordinating 
processes  originated  by  Dijkstra  and 


parallel 

occurring 


in  British  RTL.  The  idea  behind  it  is  that  one 
may  initialize  a counter  so  that  as  each  of  se- 
veral processes  arrives  at  a desired  point,  it 
increments  the  counter  and  hangs  up  until  the 
count  is  completed  and  all  processes  have  at  a 
condition  of  coordination. 

Virtual  - Adjective  applied  to  a hardware-software  system 
which  is  designed  to  look  like  or  simulate  an 
equivalent  plausible  hardware  system. 

Virtual  Memory  - A mass  storage  filing  point  of  view  which 
permits  programs  to  operate  as  if  they  had  un- 
limited core  (up  to  the  amount  of  mass  storage 
available)  and  machine  instruction  set. 

Virtual  Machine-  An  abstract  machine  (which  could  be  simulated 
in  another  machine)  used  to  define  the  meaning  of 
more  elaborate  languages  or  to  facilitate  inter- 
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machine  transportability  of  programming  languages. 
Generally  it  would  be  designed  to  be  simply  simu- 
lated and  unambiguously  interpreted,  whereas  the 
more  elaborate  languages  would  be  more  difficult 
to  compile  directly.  A general  compiler  may  then 
be  written  into  the  virtual  machine. 

The  following  definitions  will  be  prepared  by  the  Committe.-: 

Definitions: 

Analog  Input 

Analog  Output 

Digital  Input 
(Contact  closer) 

Digital  Output 

Functional  Processor 

Central  Processor 

Batch  Process 

Continuous  Process 

Sequences 

Conditionals 

Language 

Procedure 

Object 

Variable 

Data 

Operators 

Devices  (simple  composited) 


PRELIMINARY  RECOMMENDED  SPECIFICATION 


AND  PROCEDURE  FOR  A PROCESS  ORIENTED  LANGUAGE 


VARIABLE: 


1.1  Process  Variable  Input 


Specifications 


Signal  Type 


Analog  Input 
Pulse  Input 
Code  Input 


(?)  Procedure  to  Input 


Device  Address 

Terminal  Address 

Processing  Sequence  (Scan  Bl< ok) 


Validity  Check 
Required  Act.l on/Mesrage 


Compensati;  n 
Conversion  Equations 
Coefficients 


r. 'ion  Parameters 


Filter  Type 
Filtering  Factors 


Instrument  Limit 
Process  Variable  Limit 
Rate  of  Change  Limit 
Set  Point  Limit 
No.  of  Repeat  reads 
before  declaring  fault 
Deadband  to  Action 
Required  Action/Message 


Limit  Check 


Variable  Description 
Eng.  Unit 
Variable  Name 


Information 
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Procedures 

(1)  Read  Mode:  Random,  Sequential 

(2)  Action  on  Completion 

(3)  Rate  of  update 

(4)  Base  Time  of  update 

(5)  Accumulation  of  past  results 

(6)  Average  and  Min.  Max. 

(7)  Storage 


(8)  Option 

1.2  Process  Variable  Output 
Specifications 

(1)  Signal  Type 

(2)  Procedure  to  Output 

(3)  Validation 

(4)  Conversion  Parameters 

(5)  Limit  Check 


Error  Condition  Keep 
Read  Stop 
Recovery  Action 
Replace  Action  of  Variable 


Pulse  Train 
Pulse  Width 
Code 

Analog  Output 

Device  Address 
Terminal  Address 
Processing  Sequence 

Illegal 

Required  Action/Message 

Absolute/Incremental 
Code  Conversion 
Encode 

Instrument  Limit 
Move  Limit 

Rate  of  Change  Limit 
Feed  Back  Input  Limit 
Required  Action/Message 
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(6) 

Information 

> 

Variable  Description 
Eng.  Unit 
Variable  Name 

Procedures 

(1) 

Order  of  the  output 

(2) 

Action  on  Completion 

(3) 

Rate  of  output 

(4) 

Base  Time  of  output 

(5) 

Computer  Override 

9 

Automatic 

Manual 

Hold 

(6) 

Option 

9 

Error  Condition 

1.3 

Logical  (digital)  inputs 

Specifications 

(1) 

Input  Address 

9 

Device  Address 
Terminal  Address 
Bit  Position 

(2) 

Validation 

9 

Validity- 

Required  Action/Message 

(3) 

Conversion  Parameter 

9 

Mask  for  Bits  Selection 
Logical  Expression 

(4) 

Initial  Condition  or 

Normal 

State 

(5) 

Alarm  Condition 

9 

Change  Status 

Abnormal 

Required  Action/Message 

Status  Description 
Bit  Name 


(6)  Information 


9 
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Procedures 


(1)  Read  Mode  (random,  sequaential) 

(2)  Action  on  Completion 

(3)  Rate  of  update 

(4)  Base  Time  of  update 

(5)  Detection  of  State  Change 

(6)  Storage 

(7)  Option 


Error  Condition  Keep 
Read  Stop 
Recovery  Action 
Replace  Action 


1.4 

Logical  (digital)  output 

Specifications 

(1) 

Signal  Type 

9 

Momentary 

Latch 

Pulse 

(2) 

Output  Address 

9 

Device  Address 
Terminal  Address 
Bit  Position 

(3) 

Validation 

9 

Illegal 

Required  Action/Message 

(4) 

Conversion  Parameters 

9 

Mask  for  Bit  Selection 
Logical  Expression 

(5) 

Normal  State  or  Initial 

Condition 

(6) 

Alarm  Condition 

9 

Abnormal 

Feed  Back  Check 

Required  Action/Message 

(7) 

Information 

9 

Status  Description 

Bit  Name 


; 

( 

: 
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Procedures 


(1) 

Order 

(2) 

Action  on  Completion 

P) 

Rate  of  Output 

p) 

Base  Time  of  Output 

(5) 

Duration  of  Pulse 

P) 

Computer  Override 

9 

Automatic 

Manual 

Hold 

(7) 

Option 

9 

Error  Condition  Keep 
Feed  Back  Input  Action 
Output  Halt 
Recovery  Action 
Replace  Action 

5 

User’s  Interrupt 

Specifications 

(1) 

Interrupt  Type 

9 

Hardware,  Software 

(2) 

Interrupt  Address 

9 

Level 

Position 

P) 

Conversion  Parameter 

9 

Mask  for  Receiving 
Logical  Expression 

(4) 

Alarm  Condition 

9 

Normal 

Abnormal 

(5) 

Information 

9 

Status  Description 
Point  Name 

Procedures 

(1) 

Interrupt  Receive 

> 

Mask  or  Unmask 

(2) 

Branch  Vector 

f 

Level  Assignment 
Branch  Address 
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(3)  Action  on  Completion 

(4)  Save  Status 


1.6  Intermediate  Variable 
Specifications 


(1) 

Variable  Address 

(2) 

Calculation 

9 

Calc.  Equation 
Independent  Variables 
Coefficients 

(3) 

Limit  Check 

9 

Variable  Limit 
Rate  of  Change  Limit 
Deadband  to  Action 
Required  Action/Message 

(4) 

Information 

9 

Variable  Description 

Eng.  Unit 
Variable  Name 


Procedures 

( 1)  Order  of  Update 

(2)  Action  on  Completion 

(3)  Rate  of  Update 

(4)  Base  Time  of  Update 

(5)  Storage 

(6)  Option  ; Reset 

2.  D D C 

Specifications 

( 1)  Control  Type 

(2)  Process  Variable  Input  ID 

(3)  Process  Variable  Output  ID 


(4)  Control  Parameter 
& Data  Source 


9 


Gain 

Reset  Time 
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(5)  Set-Point  Value 
& Data  Source 

(6)  Valve  Status 

(7)  Limit  Check 


(8)  Information 


Procedures 


(1)  Triggering  Order 

(2)  Rate  of  Update 

(3)  Base  Time  of  Update 

(4)  Loop  Actuation  ; 

(5)  Set  Point  Change  ; 

(6)  Parameter  Change  & Tracking 

(7)  Storage 

(8)  Option  ; 


Rate  Time 
Derivative 
Filter  Gain 
Dead  Time 

Gap  Width  (Minimum  Output) 
Other  Non-linear  Factor 

Value 
Loop  Name 
Cascade  Level 

Direct/Reverse 
Feed  Back  Point 

Loop  Condition 
( On, Off , Fault) 

Rate  of  Change  Limit 
Feed  Back  Input 
Required  Action/Message 

Loop  Description 
Eng.  Unit 
Loop  Name  (No.) 


Automatic 

Manual 

Hold 

Increase/Decrease 
Data  Source 


Error  Condition 
Feed  Back  Action 
Recovery  Action 
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Replace  Loop  With  Alternate 
Manual  Manipulation 


C ommand s 


(l)  Select  Standard  DDC  Algorithm 


ALG  type 
Exp.  of  type 
Style  a : 


3.  Sequence  Control 
Specifications 


Signal  add,  split,  etc. 
Standard  transfer  function 


Standard  Function  Generator 


Comparator 
Optional  element 


Under  Study 


Procedures 


Under  Study 


Commands  (Reference) 

(l)  Status  Detecting  Command 

SDET  type 
Exp.  of  type 

Style  a : i 


(2)  Action  Request  Command 

RQST  type 
Exp . of  type 

Style  a : 


Sequence  Step  Initialize 
Process  Status  Change 
Interrupt 

Intermediate  Variable  Change 


Sequence  Step  Initialize 
Sequence  Execute 
Sequence  Monitor 
Sequence  Hold 
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Style 

e 

Sequence  Stop 

V 

f 

Sequence  Skip 

r? 

g 

Call  Special  Function 

Timer  Active  Command 

STIM  type 

Exp.  of  type 

Style 

a 

Set  Timer 

If 

b 

Read  Timer 

11 

c 

Timer  Active 

If 

d 

Timer  Hold 

11 

e 

Timer  Delay 

(4)  Transfer  Control  Command 

STRN  type 
Exp.  of  type 

Style  a : Branch  Sequence  Step 
" b : Return  End 

(5)  Logical  Command 

Same  Type  in  Digital  Input  of  Characteristics 
(Third  Workshop,  Part  1,  P.  80) 

4.  File  Builder 


Specification 

(l)  File  Type  ; System  File 

Variable  File 
Message  File 
Constant  File 
System  Common  File 

User's  Defined  File 


(2) 

File  Name 

(5) 

Device 

(*) 

Organization 

9 

Random 
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Index  Sequential 
Sequential 

(5) 

File  Type 

; Fixed  Length 

Dynamic  Expandable 

(6) 

Record  Type 

; Fixed 

Variable 

(7) 

File  Size 

(8) 

Record  Size 

(9) 

File  Protection 

* 

Procedures 

(1) 

Define  File 

File  Set  Up 

DEFN  type 

type  = Characteristic  of  File 

(2)  Direct  Access 

(a)  READ  type 

type  = File  Name  and  Position 

(b)  WRITE  type 

type  = File  Name  and  Position 

(3)  File  Access 

Under  study  for  file  open,  close,  read  and  write 
procedure. 

5.  Man-Machine  Communication 
Specifications 
( 1)  Data  Display 

(a)  Identification  ; Data  Type 

Point  No. 

Time 


(b)  Device 
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( c)  Display  Mode 


(d)  Display  Format 


(3)  ID  Entry  Method 
Data 

(a)  Identification 

(b)  Device 

(c)  Value  Limit 

( d)  Entry  Format 


(e)  ID  Entry  Method 

(f)  Value  Entry  Method 

( g)  Display  Mode 

Trend  Recording 

(a)  Identification 


(b)  Time  Marker 

(c)  Device 

(d)  Recording  Mode 

(e)  Start  Message  Code 


Instantaneous 
Continuous  Update 
Cyclic  Point 

Point  ID 
Value 

Decimal  Point 

Unit 

Text 


Data  Type 
Point  No. 

Time 

High  Limit  Value 
Low  Limit  Value 
Point  ID 
Value 

Decimal  Point 

Unit 

Text 


Point  No.  1 (e.  g.  Pen, 
display) 

Point  No.  n 


bus , 
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(*0 

Message  Form 

(a) 

Message  Code 

(to) 

Device 

(c) 

Data  Point  Sequence  for  logs 

(d) 

Data  Format  Sequence  for  logs 

(5) 

Request  Function  (operator  functions) 

(a) 

Function  Code 

(to) 

Branch  Vector 

(c) 

Receive  Condition 

(d) 

Terminate  Condition 

Procedures 

(1) 

Active  and  Passive  Entry 

(a) 

Request  Receive 

(to) 

Action  on  Completion 

(c) 

Entry  Data  Receive 

(d) 

Display  Data 

(e) 

Acknowledge  input  and  Store  Data 

(f) 

Message  Output 

(S) 

Cyclic  Action 

(2) 

Alarm 

Display 

(a) 

Trigger  Condition 

(to) 

Action  on  Completion 

(c) 

Error  Condition  Acknowledgement 

(d) 

Alarm  Display 

(e) 

Message  Output 

(f) 

Clear  Alarm 

(5)  Graphic  Display 

(a)  Pattern  Generation  (Selection) 

(b)  Order 

(c)  Action  on  Completion 

(d)  Selection  of  Display  Mode;  Vector  Mode  or 
Character  Mode 


(e)  Repetitive  Display 

(4)  Control  Loop  Manipulation 

(a)  Loop  Condition  Change 

(b)  Loop  Status  Display 

(c)  Loop  Add 

(d)  Loop  Delete 

(e)  Loop  Modification 

(5)  Memory  Display  and  Change 

(a)  Memory  Address  Set 

(b)  Memory  Display 

(c)  Memory  Change 

( d ) Print 


6.  User's  Maintenance  (optional) 
Specifications 

(l)  Error  Identification  ; 


(2)  Error  Priority 

(3)  Error  Condition  Description 

(4)  Error  Branch  .Vector 


(5)  Maintenance  Block  and  Action 
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(7)  Recovery  Action 

(8)  Error  Message  Code 

Procedures 

(1)  Error  Handling 

(a)  Error  Detection  and  Branch 

(b)  Save  Status  (Mark  Down  by  Computer) 

(c)  Device  Failure  Set  (Mark  Down  by  Operator) 

(d)  Device  Replace  (Alternative  Device) 

(e)  Device  Restart  (Markup) 

(2)  Program  Debug 

(a)  Trace 

(b)  Conditional  Dump 

(c)  Break  Point  Set 

7.  Inter  System  Communication 
Under  Study 


WORKING  DOCUMENT 
FOR 

THE  SPECIFICATION  OF  A 
PROBLEM  ORIENTED 
LANGUAGE 


PWFSOICL,  POLC 
March,  1971 


-198- 


FOREWORD 


This  description  presents  the  form  for  and  the  inter- 
pretation of  programs  written  in  the  common  programming 
language  for  use  on  industrial  computer  systems. 


Suggestions  for  improvement  gained  in  the  review  of 
this  material  will  be  welcome.  They  should  be  sent  to 


the  Chairman,  POL  Committee. 


-199- 


contents 


SECTION 


1 . Purpose  and  Scope 

1.1  Purpose 

1.2  Scope 

2.  Basic  Terminology 

3.  Program  Form 

3.1  The  Language  Character  Set 

3.2  Statements 

3.3  Statement  Label 

3.4  Names 


4.  Data  Types 

4.1  Data  Type  Association 

4.2  Data  Type  Properties 


5. 


Data  and  Procedure  Identification 

5.1  Data  and  Procedure  Names 

5.2  Function  Reference 

5.3  Type  Rules  for  Data  and  Procedure  Identifiers 

5.4  Dummy  Arguements 


6.  Expressions 

6.1  Arithmetic  Expressions 

6.2  Relational  Expressions 

6.3  Logical  Expressions 

6.4  Evaluation  of  Expressions 


7.  Statements 

7.1  Executable  Statements 

7.2  Nonexecutable  Statements 


-200- 


LANGUAGE  DESCRIPTION 

1.  PURPOSE  AND  SCOPE 

1 . 1 Purpose 

This  description  establishes  the  form  for  and  the  inter- 
pretation of  programs  expressed  in  the  language  for  the 
purpose  of  promoting  a high  degree  of  interchangeability 
of  such  programs  for  use  on  a variety  of 
computer  systems.  A processor  shall  conform  to  this 
standard  provided  it  accepts,  and  interprets  as  specified, 
at  least  those  forms  and  relationships  described  herein. 

Insofar  as  the  Interpretation  of  the  language  form  and 
relationships  described  are  not  affected,  any  statement 
of  requirement  could  be  replaced  by  a statement  expressing 
that  the  standard  does  not  provide  an  interpretation  un- 
less the  requirement  is  met.  Further,  any  statement  of 
prohibition  could  be  replaced  by  a statement  expressing 
that  the  description  does  not  provide  an  interpretation 
when  the  prohibition  is  violated. 

1.2  Scope 

This  description  establishes: 

(1)  The  form  of  a program  written  in  the  language. 

(2)  The  form  of  wri  ting  input  data  to  be  processed  by 


such  a program  operating  on  industrial  computer 
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systems  (to  be  defined) . 

. 

(3)  Rules  for  interpreting  the  meaning  of  such  a program. 

(4)  The  form  of  the  output  data  resulting  from  the  use  of 

such  a program  on  computer  systems, 

provided  that  the  rules  of  interpretation  establish 
an  interpretation  (to  be  defined)  . 

1.2.1  This  description  does  not  prescribe: 

(1)  The  mechanism  by  which  programs  are  transformed  for 
use  on  a computer  system  (the  combination  of 
this  mechanism  and  computer  system  is  called  a 
processor) . 

(2)  The  method  of  transcription  of  such  programs  or  their 
input  or  output  data  to  or  from  a computing 
medium. 

(3)  The  manual  operations  required  for  set-up  and  control 

of  the  use  of  such  programs  on  computer  equip- 
ment . j 

(4)  The  results  when  the  rules  for  interpretation  fail  to 
establish  an  interpretation  of  such  a program. 

(5)  The  size  or  complexity  of  a program  that  will  exceed 
the  capacity  of  any  specific  computer  system  or 
the  capability  of  a particular  processor. 

(6)  The  range  or  precision  of  numerical  quantities. 

1.2.2  The  Intra-  and  Inter-Program  relationships  of  this  language  . 


shall  be  defined. 


BASIC  TERMINOLOGY 


This  section  introduces  some  basic  terminology  and  some  concepts. 

A rigorous  treatment  of  these  is  given  elsewhere.  Certain  conven- 
tions concerning  the  meaning  of  grammatical  forms  and  particular 
words  are  presented. 

A program  that  can  be  used  as  a self-contained  computing  procedure 
is  called  an  executable  program. 

An  executable  program  consists  of  precisely  one  main  program  and 
possibly  one  or  more  subprograms. 

A main  program  is  a set  of  statements  and  comments. 

A subprogram  is  similar  to  a main  program  but  is  headed  by  a 
BLOCK  DATA,  FUNCTION,  or  SUBROUTINE  statement.  A subprogram  headed 
by  a SPECIFICATION  statement  is  called  e.  specification  subprogram. 

A subprogram  headed  by  a FUNCTION  or  SUBROUTINE  statement  is  called 
a procedure  subprogram. 

The  term  program  unit  will  refer  to  either  a procedure  or  a specifi- 
cation program.  ^ The  term  procedure  will  refer  to  either  a main- 
program  or  a procedure  subprogram. 

Any  program  unit  except  a specification  subprogram  may  reference 
a global  procedure. 

A global  procedure  that  is  defined  by  statements  is  called  a pro- 
cedure subprogram.  Global  procedures  also  may  be  defined  by  other 
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means.  A global  procedure  may  be  a global  function  or  a global 
subroutine.  A global  function  defined  by  statements  headed  by 
a FUNCTION  statement  is  called  a function  subprogram.  A global 
subroutine  defined  by  statements  headed  by  a SUBROUTINE  statement 
is  called  a subroutine  subprogram. 

There  is  a type  of  statement  called  a NOTE  statement  that  merely 
provides  information  for  documentary  purposes. 

The  statements  in  this  language  fall  into  two  broad  classes  - 
executable  and  none^cutable . The  executable  statements  specify 
the  action  of  the  program  while  the  nonexecutable  statements 
describe  the  use  of  the  program,  the  characteristics  of  the  oper- 
ands, editing  information,  statement  functions,  or  data  arrange- 
ment . 

The  syntactic  elements  of  a statement  are  names  and  operators. 
Names  are  used  to  reference  objects  such  as  data,  procedures,  or 
devices.  Operators  , including  the  imperative  verbs,  specify 
action  upon  named  objects. 

One  class  of  name,  the  array  name,  deserves  special  mention.  An 
array  name  must  have  the  size  of  the  identified  array  defined  in 
an  array  declarator.  An  array  name  qualified  only  by  a subscript 
is  used  to  identify  a particular  element  of  the  array. 

Data  names  and  the  arithmetic  (or  logical)  operations  may  be 
connected  into  expressions.  Evaluation  of  such  an  expression 
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develops  a value.  This  value  is  derived  by  performing  the 
specified  operations  on  the  named  data. 

The  identifiers  used  in  the  language  are  names.  Data  are  named. 
Procedures  are  named.  Statements  are  labeled  with  names  followed 
by  a colon. 

At  various  places  in  this  description,  there  are  statements  with 
associated  lists  of  entries.  In  all  such  cases  the  list  is 
assumed  to  contain  at  least  one  entry  unless  an  explicit  exception 
is  stated.  As  an  example,  in  the  statement 
SUBROUTINE  s a1,  a2,  ...  an 

it  is  assumed  that  at  least  one  symbolic  name  is  included  in  the 
list.  A list  is  a set  of  identifiable  elements  each  of  which  is 
separated  from  it  successor  by  a comma  and/or  a space.  Further, 
in  a sentence  a plural  form  of  a noun  will  be  assumed  to  specify 
also  the  singular  form  of  that  noun  as  a special  case  when  the 
context  of  the  sentence  does  not  prohibit  this  interpretation. 


PROGRAM  FORM 


Every  program  unit  is  constructed 
statements . 

3 . 1 The  Language  Character  Set 
A program  unit  is  written 

A,  B,  C,  D,  E,  F,  G,  H, 

T,  U,  V,  W,  X,  Y,  Z,  0, 
Character 


+ 

* 

/ 

( 

) 

i 

$ 


? 


of  characters  grouped  into 


using  the  following  characters 
J,  K,  L,  M,  N,  0,  P,  Q,  R,  S, 
1,  2,  3,  4,  5,  6,  7,  8,  9,  and: 
Name  of  Character 
Space 
Equals 
Plus 
Minus 
Asterisk 
Slant 

Left  Parenthesis 
Right  Parenthesis 
Comma 

Decimal  Point  or  Period 

Currency  Symbol 

Semicolon 

Colon 

Apostrophe 

Question  Mark 

Underline 


I, 


The  order  in  which  the  characters  are  listed  does  not 
Imply  a collating  sequence. 


— — - — — — 
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3.1.1  Digits: 

A binary  digit  is  either  a 1 or  a 0. 

An  octal  digit  is  a binary  digit  or  one  of  the  following 
six  characters:  2,  3,  4,  5,  6,  7. 

A decimal  digit  is  an  octal  digit  or  one  of  the  following 
two  characters:  8,  9. 

A hexadecimal  digit  is  a decimal  digit  or  one  of  the 
additional  six  characters:  A,  B,  C,  D,  E,  F. 

Strings  of  digits  representing  numeric  quantities  are  inter- 
preted in  the  decimal  base  number  system,  unless  otherwise 
specified . 


3.1.2  Letters: 

A letter  is  one  of  the  twenty-six  characters:  A,  B,  C,  D, 

E,  F,  G,  H,  I,  J,  K,  L,  M,  N,  O,  P,  Q,  R,  S,  T,  U,  V,  W,  X, 
Y,  Zf 


3.1.3  Alphanumeric  Characters: 

An  alphanumeric  character  is  a letter  or  a digit. 

3.1.4  Special  Characters: 

A special  character  is  one  of  the  following  sixteen 
characters:  Space,  Equals,  Plus,  Minus,  Asterisk,  Slant, 

Left  parenthesis.  Right  parenthesis.  Comma,  Period,  Currency 
Symbol,  Semi-colon,  Colon,  Apostrophe,  Question  Mark,  and 


Underline . 


3.1.5  Spaces: 
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A string  of  spaces  occupying  consecutive  columns  has  the 
same  meaning  for  the  Processor  as  a single  space.  Any 
special  character  excluding  the  underline  character, 
surrounded  by  spaces,  represents  itself. 

3 . 2 Statements 

A statement  is  a string  of  characters  of  the  character 

set.  Statements  consisting  entirely  of  spaces  are  called 
empty  statements  and  are  ignored  by  the  Processor. 

The  character  positions  in  the  statement  are  termed  columns. 

Columns  are  numbered  consecutively  starting  at  the  left  and 
proceeding  to  the  right.  The  leftmost  column  is  column  1. 

The  rightmost  column  contains  a semi-colon  and  marks  the 
end  of  the  statement. 

3.2.1  NOTE  Statement: 

The  first  five  significant  characters  of  a note  statement 
are  NOTE:  designating  the  statement  as  a comment.  This 

statement  does  not  affect  the  program  and  may  be  used  freely 
to  improve  the  clarity  of  the  text. 

A NOTE  statement  may  not  be  the  last  statement  of  a program. 

3.2.2  END  Statement: 

The  significant  characters  of  the  statement  must  be  END; 
designating  the  end  of  the  written  description  of  the  program. 
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Every  program  must  physically  terminate  in  the  END  state- 
ment . 

There  must  be  exactly  one  END  statement  in  a program. 

3.2.3  Ordering  of  Statements: 

Statements  are  numbered  consecutively  in  the  order  of  presen- 
tation to  the  Processor.  The  statement  which  is  first 
presented  is  statement  1. 

Two  non-empty  statements  are  equivalent  if  they  contain  the 
same  ordered  set  of  words . 

Two  empty  statements  are  always  equivalent. 

Two  programs  are  equivalent  if  they  contain  the  same  ordered 
set  of  non-empty  statements  (assuming  that  note  statements 
are  ignored) . 

3 . 3 Statement  Label 

A statement  may  be  labeled  so  that  it  may  be  referred  to  in 
other  statements.  A statement  label  consists  of  a name 
followed  by  a colon. 


3.4  Names 

A name  consists  of  one  to  32  alphanumeric  or  underline  charac- 
ters, the  first  of  which  must  be  alphabetic  or  the  underline 
character . 
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4 . DATA  TYPES 

Eight  different  types  of  data  are  defined.  These  are  integer, 
scaled  integer,  real,  extended  integer,  extended  scaled  integer, 
extended  real,  logical,  and  character.  The  term  numeric  data 
is  used  to  indicate  integer,  scaled  integer,  real,  extended  in- 
teger, extended  scaled  integer,  and  extended  real  data.  The 
term  non- numeric  data  is  used  to  indicate  logical  and  character 
data.  The  term  extended  type  is  used  to  indicate  extended  integer, 
extended  scaled  integer  or  extended  real  data. 

Each  type  has  a different  mathematical  significance  and  may  have 
different  internal  representation.  Thus  the  data  type  has  a sig- 
nificance in  the  interpretation  of  the  associated  operations  with 
which  a datum  is  involved.  The  data  type  of  a function  defines  the 
type  of  the  datum  it  supplies  to  the  expression  in  which  it  appears 

4 . 1 Data  Type  Association 

The  name  employed  to  identify  a datum  or  function  carries 
the  data  type  association.  The  form  of  the  string  represent 
ing  a constant  defines  both  the  value  and  the  data  type. 

A symbolic  name  representing  a function,  variable,  or  array 
must  have  only  a single  data  type  association  for  each  pro- 
gram unit.  Once  associated  with  a particular  data  type,  a 
specific  name  implies  that  type  for  any  differing  usage  of 
that  symbolic  name  that  requires  a data  type  association 
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throughout  the  program  unit  in  which  it  is  defined. 


Data  type  must  be  established  for  a symbolic  name  by  decla- 
ration in  a type-statement  for  all  data  types. 


4 . 2 Data  Type  Properties 

The  mathematical  and  the  representation  properties  for  each 


of  the  data  types  are  defined  in  the  following  sections. 


For  numeric  data  the  value  zero  is  considered  neither 
positive  nor  negative. 


4.2.1  Integer  Type: 

An  integer  datum  is  always  an  exact  representation  of  an 
integer  value.  It  may  assume  positive,  negative,  and  zero 
values.  It  may  only  assume  integral  values. 


4.2.2  Real  Type: 

A real  datum  is  a processor  approximation  to  the  value  of  a 
real  number.  It  may  assume  positive,  negative,  and  zero 
values . 


4.2.3  Scaled  Integer  Type: 

A scaled  integer  datum  is  second  form  of  real  data. 
(Radixpt  is  implicit  in  data) 


4.2.4  Extended  Type: 

An  extended  datum  is  a processor  approximation  to  the  value 
of  integer,  real,  or  scaled  integer  number.  It  may  assume 


-211- 


positive,  negative,  and  zero  values.  The  degree  of  approxi- 
mation though  undefined  must  be  greater  than  that  of  the 
types  integer  real,  and  scaled  integer  respectively. 

4.2.5  Logical  Type: 

A logical  datum  may  assume  only  the  truth  values  of  true 
or  false. 

4.2.6  Character  Type: 

A character  datum  is  a string  of  characters.  ring 

may  consist  of  any  characters  capable  of  representation,  in 
the  processor.  The  blank  character  is  a valid  and  significant 
character  in  a character  datum. 
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5.  DATA  AND  PROCEDURE  IDENTIFICATION 

Names  are  employed  to  reference  or  otherwise  identify  objects, 
including  data  and  procedures. 

The  term  reference  is  used  to  indicate  an  identification  of  a datum 
implying  that  the  current  value  of  the  datum  will  be  made  available 
during  the  execution  of  the  statement  containing  the  reference.  If 
the  datum  is  identified  but  not  necessarily  made  available,  the 
datum  is  said  to  be  named.  One  case  of  special  interest  in  which 
the  datum  is  named  is  that  of  assigning  a value  to  a datum,  thus 
defining  or  redefining  the  datum. 

The  term  reference  is  used  to  indicate  an  identification  of  a 
procedure  implying  that  the  actions  specified  by  the  procedure 
will  be  made  available. 

5 . 1 Data  and  Procedure  Names 

A data  name  identifies  a constant,  a variable,  an  array 
or  array  element,  or  a block.  A procedure  name  identifies 
a function  or  a subroutine. 

5.1.1  Constants: 

A constant  is  a datum  that  is  always  defined  during  execu- 
tion and  may  not  be  redefined.  Rules  for  writing  constants 


are  given  for  each  data  type. 


t 
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A numeric  constant  is  said  to  be  signed  when  it  is  written 
immediately  following  a plus  or  minus.  Also,  for  these 
types,  an  optionally  signed  constant  is  either  a constant 
or  a signed  constant. 


5. 1.1.1  Integer  Constant 

An  integer  constant  is  a binary  constant,  an  octal 
constant,  a decimal  constant,  or  a hexadecimal  constant. 


5. 1.1. 1.1 


5. 1.1. 1.2 


5. 1.1. 1.3 


5. 1.1. 1.4 


Binary  Constant 

A binary  constant  is  written  as  the  letter  "B"  followed 
by  a single  quote,  followed  by  a non-empty  string  of 
the  digits  0 and  1,  followed  by  a single  quote. 

Octal  Constant 

An  octal  constant  is  written  as  the  letter  "0"  followed 
by  a single  quote,  followed  by  a non-empty  string  of 
the  digits  0,  1,  2,  3,  4,  5,  6,  7,  followed  by  a 
single  quote. 

Decimal  Constant 

A decimal  constant  is  written  as  a non-empty  string  of 
the  digits  0,  1,  2,  3,  4,  5,  6,  7,  8,  9. 

Hexadecimal  Constant 


A hexadecimal  constant  is  written  as  the  letter  "X" 
followed  by  a single  quote, 

followed  by  a non-empty  string  of  the  digits  0,  1,  2, 
3,  4,  5,  6,  7,  8,  9,  and  the  letters  A,  B,  C,  D,  E,  F, 


followed  by  a single  quote. 


Real  Constant 


A basic  real  constant  is  written  as  an  integer  part,  a 
decimal  point,  and  a decimal  fraction  part  in  that  order. 
Both  the  integer  part  and  the  decimal  part  are  strings 
of  digits;  either  one  of  these  strings  may  be  empty  but 
not  both.  The  constant  is  an  approximation  to  the  digit 
string  interpreted  as  a decimal  numeral. 

A decimal  exponent  is  written  as  the  letter,  E,  followed 
by  an  optionally  signed  integer  constant.  A decimal 
exponent  is  a multiplier  (applied  to  the  constant  written 
immediately  preceding  it  ) that  is  an  approximation  to 
the  exponential  form  ten  raised  to  the  power  indicated 
by  the  integer  written  following  the  E. 

A real  constant  is  indicated  by  writing  a basic  real  con- 
stant, a basic  real  constant  followed  by  a decimal  ex- 
ponent, or  an  integer  constant  followed  by  a decimal 
exponent . 

Logical  Constant 

The  logical  constants,  true  and  false,  are  written 
TRUE  and  FALSE  respectively. 

Character  Constant 


A character  constant  is  written  as  a single  quote 
followed  by  a string  of  characters  followed  by  a single 
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quote.  Two  sequential  single  quotes  within  a character 
constant  is  interpreted  as  a single  quote. 

5.1.2  Variable: 

A variable  is  a datum  that  is  identified  by  a symbolic 
name.  Such  a datum  may  be  referenced  and  defined. 

5.1.3  Array: 

An  array  is  an  ordered  set  of  data  of  one,  two,  or  three 
dimensions.  An  array  is  identified  by  a symbolic  name. 
Identification  of  the  entire  ordered  set  is  achieved  via 
use  of  the  array  name . 

5. 1.3.1  Array  Element 

An  array  element  is  one  of  the  members  of  the  set  of 
data  of  an  array.  An  array  element  is  identified  by 
immediately  following  the  array  name  with  a qualifier, 
called  a subscript,  which  points  to  the  particular 
element  of  the  array. 

5. 1.3. 2 Subscript 

A subscript  is  written  as  a parenthesized  list  of  sub- 
script expressions.  Each  subscript  expression  is 
separated  by  a comma  from  its  successor,  if  there  is  a 
successor.  The  number  of  subscript  expressions  must 
correspond  to  the  declared  dimensionality. 

A subscript  expression  is  an  arithmetic  expression.  The 
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r 

value  of  a subscript  expression  is  the  greatest 
integer  contained  in  theevaluated  arithmetic  ex- 
pression. Following  evaluation  of  all  subscript 
expressions,  the  array  element  successor  function 

( ) determines  the  identified  array 

element . 

5.1.4  Procedures: 

A procedure  is  identified  by  a symbolic  name.  A procedure 
is  a local  or  global  function  or  subroutine.  Local  and 
global  functions  are  referred  to  as  functions  or  function 
procedures;  local  and  global  subroutines  as  subroutines  or 
subroutine  procedures. 

« 

A function  supplies  a result  to  be  used  at  the  point  of 
reference;  a subroutine  does  not.  Functions  are  referenced 
in  a manner  different  from  subroutines. 

. 

5.2  Function  Reference 

A function  reference  consists  of  the  function  name  followed 
by  an  optional  argument  list.  If  the  list  contains  more 
than  one  argument  , the  arguments  are  separated  by  commas 
or  spaces. 

5 . 3 Type  Rules  For  Data  and  Procedure  Identifiers 
The  type  of  a constant  is  implicit  in  its  name. 


1 
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There  is  no  type  associated  with  a symbolic  name  that 
identifies  a subroutine  or  a block. 

A symbolic  name  that  identifies  a variable,  an  array,  or 
a statement  function  must  have  its  type  specified  in  a 
type-statement . 

In  the  program  unit  in  which  a global  or  local  function  is 
referenced,  its  type  definition  is  defined  in  the  same  manner 
as  for  a variable  and  an  array.  For  a function  subprogram, 
type  is  specified  explicitly  in  the  FUNCTION  statement. 

The  same  type  is  associated  with  an  array  element  as  is 
associated  with  the  array  name. 

Dummy  Arguments 

A dummy  argument  of  an  external  procedure  identifies  a 
variable,  array,  subroutine,  or  external  function. 

When  the  use  of  an  external  function  name  is  specified,  the 
use  of  a dummy  argument  is  permissible  if  an  external 
function  name  will  be  associated  with  that  dummy  argument  . 

When  the  use  of  an  external  subroutine  name  is  specified, 
the  use  of  a dummy  argument  is  permissible  if  an  external 
subroutine  name  will  be  associated  with  that  dummy  argument  . 

When  the  use  of  a variable  or  array  element  reference  is 
specified,  the  use  of  a dummy  argument  is  permissible  if  a 


value  of  the  same  type  will  be  made  available  through 
argument  association. 

Unless  specified  otherwise,  when  the  use  of  a variable, 
array,  or  array  element  name  is  specified,  the  use  of  a dummy 
argument  is  permissible  provided  that  a proper  association 
with  an  actual  argument  is  made. 
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6.  EXPRESSIONS 

This  section  gives  the  formation  and  evaluation  rules  for  arith- 
metic, relational,  and  logical  expressions.  A relational  expression 
appears  only  within  the  context  of  logical  expressions.  An  ex- 
pression is  formed  from  elements  of  the  language. 
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A t-erm  is  a factor  or  a construct  of  one  of  the  forms: 
term/factor 


or: 


term*term 

A signed  term  is  a term  immediately  preceded  by  + or  - . 
A simple  arithmetic  expression  is  a term  or  two  simple 
arithmetic  expressions  separated  by  a + or  - . 


An  arithmetic  expression  is  a simple  arithmetic  expres- 
sion or  a signed  term  or  either  of  the  preceding  forms 
immediately  followed  by  a + or  - immediately  followed 
by  a simple  arithmetic  expression. 


A primary  of  any  type  may  be  exponentiated  by  an  integer 
or  extended  integer  primary,  and  the  resultant  factor  is 
the  same  type  as  the  element  being  exponentiated. 

A real  or  extended  real  primary  may  be  exponentiated  by 
a real  or  extended  real  primary,  and  the  resultant  factor 
is  of  type  real  if  both  primaries  are  of  type  real  and 
otherwise  of  type  extended  real.  These  are  the  only  cases 
for  which  use  of  the  exponentiation  operator  is  defined. 

By  use  of  the  arithmetic  operators  other  than  exponen- 
tiation, any  admissible  element  may  be  combined  with 
another  admissible  element  and  the  resultant  element  will 
have  a range  equal  to  the  maximum  range  of  any  of  its 
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constituent  elements.  By  the  range  of  an  element  is 
meant  the  absolute  difference  between  the  largest  and 
smallest  value  capable  of  representation. 

2 Relational  Expressions 

A relational  expression  consists  of  two  arithmetic  ex- 
pressions separated  by  a relational  operator  and  will  have 
the  value  true  or  false  as  the  relation  is  true  or  false, 
respectively . 

The  evaluation  of  the  relational  expression  will  use  the  lar- 
ger of  the  ranges  of  these  two  arithmetic  expressions. 

The  relational  operators  are: 

Operator  Representing 


LT 

Less  than 

LE 

Less  than  or 

equal  to 

EQ 

Equal  to 

NE 

Not  equal  to 

GT 

Greater  than 

GE 

Greater  than 

or  equal  to 

3 Logical  Expressions 

A logical  expression  is  formed  with  logical  operators  and 
logical  elements  and  has  the  value  true  or  false.  The 
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logical  operators  are: 
Operator  Representing 


OR 

Logical 

disjunction 

AND 

Logical 

conjunction 

NOT 

Logical 

negation 

EOR 

Logical 

comparison 

The  logical  elements  are  logical  primary,  logical  factor, 
logical  term,  and  logical  expression. 

A logical  primary  is  a logical  expression  enclosed  in 
parentheses,  a relational  expression,  a logical  constant, 
a logical  variable  reference,  a logical  array  element 
reference,  or  a logical  function  reference. 

A logical  factor  is  a logical  primary  or  NOT  followed  by  a 
logical  primary. 

A logical  term  is  a logical  factor  or  a construct  of  the 
form: 

logical  term  AND  logical  term 
A logical  expression  is  a logical  term  or  a construct  of 
the  form: 

logical  expression  OR  logical  expression 

6.4  Evaluation  of  Expressions 

A part  of  an  expression  need  be  evaluated  only  if  such  action 
is  necessary  to  establish  the  value  of  the  expression.  The 
rules  for  formation  of  expressions  imply  the  binding  strength 
of  operators.  It  should  be  noted  that  the  range  of  the  sub- 


A 
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traction  operator  is  the  term  that  immediately  succeeds 
it.  The  evaluation  may  proceed  according  to  any  valid 
formation  sequence  (except  as  modified  in  the  following 
paragraph) . 

When  two  elements  are  combined  by  an  operator,  the  order  of 
evaluation  of  the  elements  is  optional.  If  mathematical 
use  of  operators  is  associative,  commutative,  or  both, 
full  use  of  these  facts  may  be  made  to  revise  orders  of 
combination,  provided  only  that  integrity  of  parenthesized 
expressions  is  not  violated.  The  value  of  an  integer  or 
extended  integer  factor  or  term  is  the  nearest  integer  or 
extended  integer  whose  magnitude  does  not  exceed  the  magni- 
tude of  the  mathematical  value  represented  by  that  factor 
or  term.  The  associative  and  commutative  laws  do  not  apply 
in  the  evaluation  of  integer  or  extended  integer  terms  con- 
taining division,  hence  the  evaluation  of  such  terms  must 
effectively  proceed  from  left  to  right. 

Any  use  of  an  array  element  name  requires  the  evaluation  of 
its  subscript.  The  evaluation  of  functions  appearing  in  an 
expression  may  not  validly  alter  the  value  of  any  other 
element  within  the  expressions,  or  any  other  statement  in 
which  the  function  reference  appears.  The  type  of  the  ex- 
pression in  which  a function  reference  or  subscript  appears 
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does  not  affect,  nor  is  it  affected  by,  the  evaluation  of 
the  actual  arguements  or  subscript. 

No  factor  may  be  evaluated  that  requires  a negative 
valued  primary  to  be  raised  to  a real  or  extended  real 
exponent.  No  factor  may  be  evaluated  that  requires  raising 
a zero  valued  primary  to  a zero  valued  exponent. 

No  element  may  be  evaluated  whose  value  is  not  mathemati- 
cally defined. 


- — - — ^ 
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7 . STATEMENTS 

A statement  is  classified  as  executable  or  non-executable. 

Executable  statements  specify  actions.  Non-executable  statements 

•j 

describe  objects  and  attributes  of  objects. 

7 . 1 Executable  Statements 

There  are  three  types  of  executable  statements: 

(1)  Assignment  statements 

(2)  Program  Control  statements 

(3)  Device  Control  statements 

7.1.1  There  are  three  types  of  assignment  statements: 

(1)  Arithmetic  statements 

(2)  Logical  assignment  statements 

(3)  Character  assignment  statements 

7. 1.1.1  Arithmetic  Assignment  Statement 

The  arithemetic  assignment  statement  is  of  the  form: 

V1  = v2  * . . . Vn  - e 

Where  n must  be  at  least  one,  and  each  is  a numeric 
variable  name  or  numeric  array  element  name  of  the  same 
type  and  e is  in  an  arithmetic  expression. 

Execution  of  this  statement  causes  the  evaluation  of  the 
expression  e,  converting  the  resulting  value  into  the 
type  of  Vp  and  the  altering  of  all  V's  to  the  converted 


value . 
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7. 1.1. 2 Logical  Assignment  Statement 

The  logical  assignment  statement  is  of  the  form: 

Vi  = V2  = . . . Vn  = e 

Where  n must  be  at  least  one,  and  each  Vj_  is  a 
logical  variable  name  or  a logical  array  element  name, 
and  e is  a logical  expression.  Execution  of  this  state- 
ment causes  the  logical  expression  e to  be  evaluated 
and  its  value  to  be  assigned  to  each  of  the  logical  en- 
tities V^'s. 

7. 1.1. 3 Character  Assignment  Statement 

The  character  assignment  statement  is  of  the  form: 

Vt  = V0  =....=  V = e 
x.  z n 

Where  n must  be  at  least  one,  and  each  V]_  is  either  a 
character  variable  , or  a character  array  element,  and 
e is  either  a character  constant  consisting  of  a single 
character,  a character  variable,  or  a character  array 
element.  Execution  of  this  statement  causes  each  of  the 
' s to  assume  the  value  of  e. 

7.1.2  Program  Control  Statements: 

There  are  twelve  program  control  statements: 

(1)  GO  TO  Statements 


(2) 


IF  statements 


-227- 


(3)  Subroutine  call  statement 

(4)  RETURN  statement 

(5)  CONTINUE  statement 

(6)  REPEAT  statement 

(7)  PAUSE  statement 

(8)  PAUSE  UNTIL  statement 

(9)  WHEN  statement 

(10)  CANCEL  statement 

(11)  STOP  statement 

(12)  START  statement 

7. 1.2.1  GO  TO  Statements 

There  are  two  types  of  GO  TO  statements: 

(1)  Unconditional  GO  TO  statement 

(2)  Computed  GO  TO  statement 

7. 1.2. 1.1  Unconditional  GO  TO  Statements. 

An  unconditional  GO  TO  statement  is  of  the  form: 

GO  TO  k 

Where  k is  a statement  label. 

Execution  of  this  statement  causes  the  statement  identi- 
fied by  the  statement  label  to  be  executed  next. 

7. 1.2. 1.2  Computed  GO  TO  Statement. 

A computed  GO  TO  statement  is  of  the  form: 

GO  TO  (ki,  k2,  . . . 1^)  , i 

where  the  k's  are  statement  labels  and  i is  an  integer 


variable  reference. 
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Execution  of  this  statement  causes  the  statement  identi- 
fied by  the  statement  label  k,  to  be  executed  next,  where 
j is  the  value  of  i at  the  time  of  the  execution.  This 
statement  is  defined  only  for  values  such  that  1 = j = n. 

7. 1.2. 2 Logical  IF  Statement 

A logical  IF  statement  is  of  the  form: 

IF  (e)  S 

Where  e is  a logical  expression  and  S is  any  executable 
statement  except  a REPEAT  statement  or  another  logical 
IF  statement.  Upon  execution  of  this  statement,  the 
logical  expression  e is  evaluated.  If  the  value  of  e 
is  false,  statement  S is  executed  as  though  it  were  a 
CONTINUE  statement.  If  the  value  of  e is  true,  statement 
S is  executed. 

7.1.2. 3 Subroutine  Call  Statement 

A subroutine  call  statement  is  of  the  form: 

S ; or 

S J ; 

Where  J is  a list  of  actual  arguements. 

The  inception  of  execution  of  a call  statement  references 
the  designated  subroutine.  Return  of  control  from  the 
designated  subroutine  completes  execution  of  the  call, 
statement . 

m k 


7. 1.2. 4 RETURN  Statement 


A RETURN  statement  is  one  of  the  forms: 

RETURN  ; 

RETURN  d; 

A RETURN  statement  marks  the  logical  end  of  a procedure 

and,  thus,  may  only  appear  in  a procedure.  The  argument  d 
must  be  a dummy  argument  of  the  procedure. 

Execution  of  this  statement  when  it  appears  in  a subroutine 
causes  return  of  control  to  the  current  calling  procedure 

and,  if  d was  specified,  it  is  assumed  the  d is  associated 
with  a statement  label. 

Execution  of  this  statement  when  it  appears  in  a function 
causes  return  of  control  to  the  current  calling  procedure. 

At  this  time  the  value  of  the  function  is  made 
available . 

7. 1.2. 5 CONTINUE  Statement 

A CONTINUE  statement  is  of  the  form: 

CONTINUE  ; 

Execution  of  this  statement  causes  continuation  of  the 
normal  execution  sequence. 

7.1.2. 6 REPEAT  Statement 

A REPEAT  statement  has  one  of  the  forms: 

REPEAT  TO  X i = m^,  m^,  m^  ; 
or  REPEAT  TO  J!  i = m^,  m^  ; 

Where:  1)  Jt  is  the  label  of  a CONTINUE  statement. 


This  CONTINUE  statement  is  the  terminal 
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statement  of  the  associated  REPEAT,  and 
must  physically  follow  and  be  in  the  same 
program  unit  as  that  REPEAT  statement. 

2)  i is  an  integer  variable  name;  this  variable 
is  called  the  control  variable. 

3)  m-^,  called  the  initial  parameter;  m2,  called 
the  terminal  parameter;  and  m^,  called  the 
incrementation  parameter,  are  each  either  an 
integer  constant  or  integer  variable  reference. 
If  the  second  form  of  the  REPEAT  statement  is 
used  so  that  m2  is  not  explicitly  stated,  a 
value  of  one  is  implied  for  the  incrementation 
parameter.  At  time  of  execution  of  the  REPEAT 
statement,  m^,  m2,  and  m^  must  be  greater  than 
zero. 


Associated  with  each  REPEAT  statement  is  a 
range  that  is  defined  to  be  those  executable 
statements  from  and  including  the  first  execu- 
table statement  following  the  REPEAT,  to  and 
including  the  terminal  statement  associated 
with  the  REPEAT.  A special  situation  occurs 
when  the  range  of  a REPEAT  contains  another 
REPEAT  statement.  In  this  case,  the  range  of 
the  contained  REPEAT  must  be  a subset  of  the 
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range  of  the  containing  REPEAT. 

A completely  nested  nest  is  a set  of  REPEAT 
statements  and  their  ranges,  and  any  REPEAT 
statements  contained  within  their  ranges,  such 
that  the  first  occurring  terminal  statement 
of  any  of  those  REPEAT  statements  physically 
follows  the  last  occurring  REPEAT  statement 
and  the  first  occurring  REPEAT  statement  of  the 
set  is  not  in  the  range  of  any  REPEAT  statement. 

7. 1.2. 6.1  A REPEAT  statement  is  used  to  define  a loop.  The  action 
succeeding  execution  of  a REPEAT  statement  is  described 
by  the  following  six  steps: 

(1)  The  control  variable  is  assigned  the  value  represen- 
ted by  the  initial  parameter.  This  value  must  be 
less  than  or  equal  to  the  value  represented  by  the 
terminal  parameter. 

(2)  The  range  of  the  REPEAT  is  executed. 

(3)  If  control  reaches  the  terminal  statement,  then  after 
execution  of  the  terminal  statement,  the  control 
variable  of  the  most  recently  executed  REPEAT  state- 
ment associated  with  the  terminal  statement  is  incre- 
mented by  the  value  represented  by  the  associated 
incrementation  parameter. 

(4)  If  the  value  of  the  control  variable  after  incremen- 
tation is  less  than  or  equal  to  the  value  represented 
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by  the  associated  terminal  parameter,  then  the 
action  described  starting  at  step  2 is  repeated, 
with  the  understanding  that  the  range  in  question 
is  that  of  the  REPEAT,  whose  control  variable  has 
been  most  recently  incremented.  If  the  value  of  the 
control  variable  is  greater  than  the  value  represented 
by  its  associated  terminal  parameter,  then  the  REPEAT 
is  said  to  have  been  satisfied  and  the  control  varia- 
ble becomes  undefined. 

(5)  At  this  point,  if  there  were  one  or  more  other  REPEAT 
statements  referring  to  the  terminal  statement  in 
question,  the  control  variable  of  the  next  most  recen- 
tly executed  REPEAT  statement  is  incremented  by  the 
value  represented  by  its  associated  incrementation 
parameter  and  the  action  described  in  step  4 is  re- 
peated until  all  REPEAT  statements  referring  to  the 
particular  termination  statement  are  satisfied,  at 
which  time  the  first  executable  statement  following 
the  terminal  statement  is  executed. 

In  the  remainder  of  this  section  (7. 1.2. 6)  a logical 
IF  statement  containing  a GO  TO  is  regarded  as  a GO 

TO. 

(6)  Upon  exiting  from  the  range  of  a REPEAT  by  the  execu- 
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tion  of  a GO  TO  statement;  that  is,  other  than  by 
satisfying  the  REPEAT,  the  control  variable  of  the 
REPEAT  is  defined  and  is  equal  to  the  most  recent  value 
attained  as  defined  in  the  preceding  paragraphs. 

7. 1.2. 6. 2 A REPEAT  is  said  to  have  an  EXTENDED  RANGE  if  both  of 
the  following  conditions  apply; 

(1)  There  exists  a GO  TO  statement  within  the  range  of 
the  innermost  REPEAT  of  a completely  nested  nest 
that  can  cause  control  to  pass  out  of  that  nest. 

(2)  There  exists  ? GO  TO  statement  not  within  the  nest 
that,  in  the  collection  of  all  possible  sequences  of 
execution  in  the  particular  program  unit,  could  be 
executed  after  a statement  of  the  type  described  in 
(1) , and  the  execution  of  which  could  cause  control 
to  return  into  the  range  of  the  innermost  REPEAT  of 
the  completely  nested  nest. 

If  both  of  these  conditions  apply,  the  extended  range 
is  defined  to  be  the  set  of  all  executable  statements 
that  may  be  executed  between  all  pairs  of  control  state- 
ments, the  first  of  which  satisfies  the  condition  of  (1) 
and  the  second  of  (2) . The  first  of  the  pair  is  not  in- 
cluded in  the  extended  range;  the  second  is.  A GO  TO 
statement  may  not  cause  control  to  pass  into  the  range  of 

i 

1 


-234- 


a REPEAT  unless  it  is  being  executed  as  part  of  the  ex- 
tended range  of  that  particular  REPEAT.  Further,  the 
extended  range., of  a REPEAT  may  not  contain  a REPEAT  of 
the  same  program  unit  that  has  an  extended  range.  When 
a procedure  reference  occurs  in  the  range  of  a REPEAT, 
the  actions  of  that  procedure  are  considered  to  be  tem- 
porarily within  that  range;  i.e.,  during  the  execution  of 
that  reference. 

The  control  variable,  initial  parameter,  terminal  para- 
meter, and  incrementation  parameter  of  a REPEAT  may  not 
be  redefined  during  the  execution  of  the  range  or  extended 
range  of  that  REPEAT. 

If  a CONTINUE  statement  is  the  terminal  statement  of  more 
than  one  REPEAT  statement,  the  statement  label  of  that 
terminal  statement  may  not  be  used  in  any  GO  TO  that 
occurs  anywhere  but  in  the  range  of  the  most  deeply  con- 
tained DO  with  that  terminal  statement. 

.2.7  Pause  Statement 

The  Pause  statement  is  of  the  form: 

PAUSE  n u ; 

Where  n is  an  integer  variable  or  constant,  and  u is 
either  SECONDS,  MINUTES,  OR  HOURS. 
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The  PAUSE  statement  causes  normal  program  flow  to  be 
suspended  at  the  point  of  execution.  The  program  flow 
is  restarted  after  the  indicated  time  interval  n u has 
elapsed.  When  this  time  interval  has  elapsed,  the  program 
flow  is  restarted  at  the  statement  following  the  PAUSE 
statement . 


PAUSE  UNTIL  Command 

A PAUSE  UNTIL  command  is  of  the  form: 

PAUSE  UNTIL  ( e ) ; 

Where  e is  a logical  expression 

The  PAUSE  UNTIL  command  causes  the  normal  program  flow 
to  be  suspended  at  the  point  of  execution.  The  program 
flow  is  restarted  when  the  expression  e is  TRUE.  When 
the  expression  becomes  TRUE,  the  program  flow  is  re- 
started at  the  statement  following  the  PAUSE  UNTIL  command. 

WHEN  Statement 

A WHEN  statement  is  of  the  form: 

X : WHEN  ( e ) S ; 

Where  e is  a logical  expression,  and  S is  an  executable 
statement  , except  WHEN  ; a is  a statement  label. 


The  execution  of  the  WHEN  statement  does  not  affect  normal 


program  flow.  However,  if  following  the  execution  of 


statement  X the  expression  e becomes  true,  the  normal 
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program  flow  is  interrupted  and  statement  S is  executed. 
Following  the  execution  of  S normal  program  execution 
is  resumed  without  loss  of  continuity.  A WHEN  statement 
remains  active-  from  the  point  of  execution  until  it  is 
negated  by  a CANCEL  statement. 

7.1.2.10  CANCEL  Statement 

The  CANCEL  Statement  is  of  the  form: 

CANCEL  X 7 

Where  i is  a statement  label.  The  execution  of  this 
statement  cancels  the  WHEN  statement  whose  label  is  e. 

7.1.2.11  STOP  Statement 

The  STOP  statement  is  of  the  form: 

STOP  ; 

or  STOP  p ; 

Where  p is  a program  name. 

If  used  alone  (STOP) , this  statement  terminates  the 
execution  of  the  program  in  which  it  is  located.  There- 
fore, it  should  be  located  at  the  logical  end  of  the 
program.  One  or  more  than  one  such  STOP  statements  can 
be  used  in  a program.  * 

If  used  with  the  arguement  p (STOP  p ) , this  statement 
terminates  the  execution  of  program  p. 
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called  a type  statement. 


7.2.2  Array-Declarator; 

An  array  declarator  specifies  an  array  used  in  a program 
unit . 


i 


The  array  declarator  indicates  the  symbolic  name,  the  number 
of  dimensions,  (one,  two,  or  three) , and  the  size  of  each 
of  the  dimensions.  The  array  declarator  form  may  be  in  a 
type-statement . 

An  array  declarator  has  the  form: 

v (i) 

Where:  (1)  v,  called  the  declarator  name,  is  a symbolic 
name . 

(2)  (i) , called  the  declarator  subscript,  is  composed 

of  1,  2,  or  3 expressions,  each  of  which  may  be 
an  integer  constant  or  an  integer  variable  name. 
Each  expression  is  separated  by  a comma  from  its 
successor  if  there  are  more  than  one  of  them. 

In  the  case  where  i contains  no  integer  variable, 
i is  called  the  constant  declarator  subscript. 

The  appearance  of  a declarator  subscript  in  a decla- 
rator statement  serves  to  inform  the  processor  that 
the  declarator  name  is  an  array  name.  The  number  of 


subscript  expressions  specified  for  the  array  indicates 
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its  dimensionality.  The  magnitude  of  the  values 
given  for  the  subscript  expressions  indicates  the 
maximum  value  that  the  subscript  may  attain  in  any 
array  element  name. 

No  array  element  name  may  contain  a subscript  that, 
during  execution  of  the  executable  program,  assumes 
a value  less  than  one  or  larger  than  the  maximum 
length  specified  in  the  array  declarator. 


7.2.3-  Array  Element  Successor  Function  and  Value  of  a Subscript: 

For  a given  dimensionality,  subscript  declarator,  and  sub- 
script, the  value  of  a subscript  pointing  to  an  array  element 
and  the  maximum  value  a subscript  may  attain  are  indicated 
in  Table  2.  A subscript  expression  must  be  greater  than 
zero. 


The  value  of  the  array  element  successor  function  is  obtained 
by  adding  one  to  the  entry  in  the  subscript  value  column. 

Any  array  element  whose  subscript  has  this  value  is  the 
successor  to  the  original  element.  The  last  element  of  the 
array  is  the  one  whose  subscript  value  is  the  maximum  sub- 


script value  and  has  no  successor  element. 
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TABLE  2 

VALUE  OF  A SUBSCRIPT 


Dimen- 

sionality 

Subscript 

Declarator 

Subscript 

Subscript 

Value 

Maximum 
Subscript  Val. 

1 

(A) 

(a) 

a 

A 

2 

(A,  B) 

(a,  b) 

a + A (b  - 

1)  A B 

3 

(A,  B,  C) 

(a,  b,  c) 

a + A (b  - 

1)  ABC 

+ A B (c  - 

i) : 

NOTES : 

(1)  a,  b,  and  c are  subscript  expressions. 

(2)  A,  B,  and  C are  dimensions. 

7.2.4  Integer  Statement: 

An  INTEGER  statement  is  of  the  form: 


INTEGER  Vp  v2,  v3  • • • vn 

Where  is  either  a variable  name  or  an  array  declarator. 


SECTION  VII 


JAPANESE  REVIEW  OF  THE  PROPOSALS 


OF  THE  PROBLEM- ORIENTED  LANGUAGES 


COMMITTEE 


The  several  Japanese  committees  studying  the  field  of 
industrial  computer  systems  and  software  have  been  extremely 
helpful  to  the  several  workshops  even  before  the  formation 
of  the  Japanese  Regional  Branch  of  the  International  Purdue 


Workshop  on  Industrial  Computer  Systems . This  material 


represents  some  of  their  contributions  to  the  work  of  the 


Problem-Oriented  Language  Committee.  The  material  appeared 


in  the  Minutes  of  the  Fourth  and  Fifth  Workshops  on  Standardi 


zation  of  Industrial  Computer  Languages , pp.  203-207  and  24- 
27  respectively. 


-243- 


Nov ember  1970 


COMMENTS  TO  THE  PROBLEM  ORIENTED  LANGUAGE  COMMITTEE 

Working  Group  for  the  Problem 
Oriented  Languages 
Technical  Committee  on  Industrial 
Computer  Languages  of  Japan 
Chairman,  T.  TOHYAMA 

1.  Present  Status  of  Problem  Oriented  Language 

At  present,  a few  computer  manufacturers  have  been  developed  the 
program  packages  for  industrial  computer  applications,  but  these 
packages  are  utilized  for  specific  application  area  and  do  not  designed 
so  much  systematic  consideration  for  the  generalized  process  control 
oriented  language. 

We  recognize  the  importance  and  the  necessity  of  standardization 
of  problem  oriented  language  and  hope  further  expansion  of  this  work. 

It  is  user's  basic  requirement  to  design  computer  control  system 
as  possible  as  easy  and  economic,  and  to  improve  system  at  plant-site. 
Besides,  the  standardization  of  specification  for  application  is  im- 
portant to  get  effectiveness  in  system  development  and  system  mainte- 
nance of  various  computers. 

In  Japan,  the  trend  of  standardization  of  problem  oriented  language 
is  not  enhanced  sufficiently.  But,  we  find  the  necessities  and  the 
activities  of  standardization  of  industrial  computer  language  through 
workshops  at  Purdue  University. 

We  have  Working  Group  for  the  Problem  Oriented  Language  and  study 
your  reports  of  workshop.  Our  group  just  started  to  investigate  the 
requirement  and  the  specification  of  problem  oriented  language.  Here- 
in, we  show  the  comments  and  our  idea  to  the  report  of  the  Problem 
Oriented  Language  Committee  at  the  3rd  Workshop. 


A mms2J!ZZ. 
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2;  Comments 

Followings  are  comments  and  requirements  to  develop  the  standard- 
ization of  Problem  Oriented  Language  (POL). 

(1)  It  is  the  1st  step  of  work  to  describe  the  detail  specifications 

of  hardware  and  software  interfaces  for  industrial  computer  system. 
In  2nd  step,  procedures  and  syntax  are  established  and  next  step 
Programs  or  Languages  themself  are  defined. 

(2)  Form  of  POL  has  function  of  self  documentation  and  easy  under- 
standing. 

(3)  The  conceptural  computer  system  is  basis  for  the  establishment  of 
POL.  If  this  is  basic  requirement,  it  is  important  to  describe 
the  complete  characteristics  of  computer  system. 

(4)  Following  requirements  are  options  of  POL  developer  for  user's 
convenience  and  attractiveness. 

(a)  Building  block  structure  for  expansion  of  applications 

(b)  Quick  response 

(c)  Small  requirement  of  memory 

(d)  Parallel  i/o  operation 

(e)  On-line  program  development  and  maintenance 

(f)  Multiprogramming  in  multi-task 

(5)  It  is  necessary  to  provide  Level  and/or  Subset  of  POL  with  each 
functions  or  structure  in  languages. 

(6)  POL  is  supervised  under  Operating  System  (OS).  But,  POL  itself 
can  handle  interrupts  of  hardware  and  software,  and  error  handl- 
ing. 
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(7)  POL  will  be  more  rigorously  defined  below. 

(a)  Relation  of  structure  between  Procedural  Languages  and  POL 

(b)  Galling  sequence  between  each  languages 

(c)  Mixed  programming  by  using  each  languages 

(d)  File  access  method 

(8)  It  is  better  to  define  the  level  of  computer  size  for  generating 
the  object  programs  from  the  source  documentations. 

(9)  It  is  convenience  for  future  study  to  define  the  basic  configura- 
tion for  running  the  object  programs. 

(10)  Before  translation  of  POL,  the  following  procedure  are  declared. 

(a)  Hardware  Assignment 

(b)  Data  Type  Definision 

(c)  Core  Allocation 

(d)  File  Allocati  on 

5.  Scope  of  User's  Function  in  POL. 

The  following  requirements  of  POL  are  put  in  order.  We  have  idea 
to  establish  POL  to  co-operate  your  workshop. 

There  are  seven  sub-functions  proposed  under  our  working  group. 

(Detail  informations  are  shown  in  Attachment.) 

(l)  Variables 


(a) 

Process 

Variable  Input 

(*>) 

Process 

Variable  Output 

(c) 

Process 

Status  Input 

(d) 

Process 

Status  Output 

(e) 

User ' s 

Interrupt 

(f) 

Intermediate  Variable 
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(2)  DDC 

(a)  Loop  definition 

(b)  Standard  DDC  Algorithm 

(c)  Easy  construction  of  required  control  algorithm 

(3)  Sequence  Control 

(a)  Standard  Sequence  Control  Algorithm 

(b)  Easy  construction  of  required  logic  flow  chart 
At  present,  we  do  not  define  the  followings. 

• Description  of  Logic  Flow  Chart  for  computer 

• Description  of  request,  abnormal  condition  for  control 

• Specification  for  Input/Output 

(Using  Process  Status  Input  and  Output  in  Variables) 

(4)  File  Builder 

(a)  Same  file  structure  in  POL's  file  and  User's  file 

(b)  Easy  file  access  from  user's  file 

(5)  Man-Machine  Communication 

(a)  Communication  mode 

• Active  Action 

• Passive  Action 

• Alarm  Display 

(b)  Message  Format  definition 

(c)  Expandability  for  new  device 

(6)  User's  Maintenance 

(a)  Error  definition  (Process  side) 

(b)  Error  Handling 

(7)  Inter  Communication 

(a)  Computer  to  Computer 

(b)  Remote  Peripheral  Device  to  Computer 

(c)  POL  and  Procedural  Language 
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April  1971 


COMMENTS  TO  1 ROBLEM  ORIENTED  LANGUAGE 


Working  Group  i'or  the  Problem 
Oriented  Languages 
Technical  Committee  on  Industrial 
Computer  Languages  of  Japan 
Chairman,  T.  TOHYAMA 


1.  Outline  our  goals  for  the  year 

For  1971,  we  have  established  the  same  objectives  for  Problem 

Oriented  Languages  as  our  primary  concern's: 

a.  Develop  Specification  and  Procedure  for  Sequence  Control,  Inter 
Systems  Communication  and  Process  Control  Function. 

b.  Review  and  exploit  The  Preliminary  Recommended  Specification 
and  Procedure  for  the  Process  Oriented  Languages. 

c.  Develop  the  shorthand  form  (Fill  in  the  Blanks  System)  on 
Process  Oriented  Languages. 

d.  Investigate  the  necessity  and  the  requirement  for  application 
programs  in  the  industrial  computer. 


2.  Supplements  for  Specification  and  Procedure  for  a Process  Oriented 
Language 

Followings  are  supplementary  specification  and  procedure  for  the 
fourth  workshop  on  standardization. 


(A)  Sequence  Control 
Spec  if ications 

(1)  Sequence  Block 

(2)  Sequence  Step  Type 


(3)  Variable  Input  ID 


; Name 

; Digital  Logic 
Decision  Table 
Analog  Logic 
Timmer 
Trigger 

; Logical  Input 

Process  Variable  Input 
Interrupt 
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(4)  Variable  Output  ID 


(5)  Parameter 


(0)  Data  Source 


(7)  Faile  Safe  Condition 


(8)  Alarm  Condition 


(9)  Information 


; Logical  Output 

Process  Variable  Output 

; Intermediate  Variable 
Decision  Rule 
Control  Limit 

; Global 
Local 

Historical 

Multiple 

; Normal  Condition 
Hold  Condition 
Emergency  Condition 
Answer  Back  Point 

; Abnormal  Condition 

Required  Action/Message 

; Sequence  Block  Description 
Sequence  Block  Name 
Sequence  Step  Name  List 
Step  Operation  Descriptions 
Step  Operation  Condition 
Block-out  Operation  No. 


Procedures 

(1)  Order  of  Sequence  Block 

(2)  Order  of  Sequence  Step 

(3)  Action  on  Completion  of  Sequence  Step 

(4)  Action  on  Completion  of  Sequence  Block 

(5)  Interactive  Operation  of  Seqiience 

(6)  Rate  of  Update  in  Repetitive  Operation 

(7)  Detect  Status 

(8)  Action  Request  ; Initialize 

Execute 

Monitor 

Hold 

Skip 

Stop 

Call  Special  Function 


; Set 
Read 
Active 
Hold 
Delay 


(9)  Timer  Action 
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(10) 

Transfer  Control 

(11) 

Logical  and  Arithmetic  Operation 

(12) 

Parameter  Change 

& Write  Status 

(13) 

Store 

(14) 

Option 

; Emergency  Shutdown 
Standby  Shutdown 
Restart 

Partial  Auto/Partial  Manual 

(B)  Inter  Systems  Communication 

At  present,  the  following  approach  for  the  Inter  Systems 
Communication  is  performed  to  prepare  the  specification  and 
procedure. 

(1)  Computer  to  Computer 

a.  Data  Communication  Mode 

b.  Communication  Line  control 

c.  Message  Text 

d . Error  Check 

(2)  Inter  Language 

a.  Longhand  Form  and  Shorthand  Form 

b.  Problem  Oriented  Languages  and  FORTRAN 

c.  Problem  Oriented  Languages  and  Long  Term  Procedural 
Languages 

d.  Problem  Oriented  Languages  and  Assembler 

(3)  Function  of  Hierarchy  System 

a.  Hierarchy  System 

b.  Dual  System/Duplex  System 

(C)  Process  Variable  Input  from  On-line  Analyzer 
(Reference  for  Gaschromatograph) 

Specif ication 

(1)  Signal  Type 

(2)  Procedure  to  Input  ; Device  Address 

Terminal  Address 
Processing  Sequence 

; Stream  Code 


(3)  Stream  Identification 
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(4) 

Component  Identification  ; 

Component  Code 
Value  Address 

(5) 

Read  Status  ; 

Instrument  Status 
Read  Ready  Condition 
Gain  Selection 

(4) 

Validation  ; 

Validity  Check 
Required  Action/Message 

(7) 

Conversion  Parameter 

(8) 

Filtering  ; 

Filter  Type 
Filtering  Factor 

(9) 

Limit  Check  ; 

Instrument  Limit 
Process  Variable  Limit 
Rate  of  Change  Limit 

(10) 

Information  ; 

Variable  Description 
Eng.  Unit 
Variable  Name 

Procedure 

(1) 

Read  Mode 

(2) 

Select  Stream 

(3) 

Detect  Instrument  Status 

(4) 

Select  Gain 

(5) 

Action  on  Completion 

(6) 

Rate  of  Update  for  Calculation 

(7) 

Adjust  Base  point 

(8) 

Calculate  Component's  Value 

(9) 

Average  and  Min.  Max. 

(10) 

Storage 

(11) 

Option  ; 

Change  Instrument 

Read  Stop 
Recovery  Action 
Replace  Action  Variable 


i 
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SECTION  VIII 

f 

. 

DECISIONS  OF  THE  PROBLEM- ORIENTED 
LANGUAGES  COMMITTEE  RELATING  TO  THE 
TRANSLATOR  METHOD  OF  PROCEEDING 
AND  PERTINENT  LITERATURE  REFERENCES 
TO  THE  TECHNIQUES  USED 


At  the  end  of  1971  the  Problem-Oriented  Languages 
Committee  decided  upon  the  Problem-Oriented  Language  Con- 
verter and  Translator  as  their  desired  end  product  (Avenue 
2 described  earlier) . The  attached  documents  from  the 
Minutes  of  the  Sixth  Workshop  on  Standardization  of  Indus- 
trial Computer  Languages . Chapter  IV,  pp.  65-74,  and  the 
Minutes  of  the  Seventh  Workshop.  Chapter  IV,  pp.  91,  96-97, 
and  102-134.  The  latter  pages  reproduce  several  of  the 
definitive  papers  by  Professor  W.  M.  Waite  of  the  University 
of  Colorado,  on  STAGE  2,  the  basic  work  in  the  translator 
area. 

„ L 
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REPORT  OF  THE  PROBLEM  ORIENTED  LANGUAGES  COMMITTEE 
SIXTH  WORKSHOP  ON  STANDARDIZATION  OF  INDUSTRIAL  COMPUTER 

LANGUAGES 


Based  upon  the  results  of  the  10th  Meeting  of  the 

Committee  attached  herein  and  of  further  discussion  during 

this  Workshop  the  POL  Committee  has  adopted  the  following 

resolution  concerning  its  future  work: 

The  Pol  Committee  will  now  concern  itself  with 
defining  the  facility  (POLCAT  STRUCTURE)  which 
will  allow  the  generation  of  POL’s  that  are 
compatible  with  the  LTPL  and  that  all  have  the 
same  basic  structure. 

To  illustrate  this  proposal  the  Committee  has  worked 
out  the  defining  example  of  Figures  1-4  as  illustrations  of 
the  work  contemplated. 

It  is  estimated  by  the  Committee  that  this  effort  will 
require  the  equivalent  of  one  man  year  of  work. 

If  four  Committee  meetings  are  held  each  year  (two  at 
the  Workshops  and  two  at  intermediate  times)  for  an  average 
of  two  days  with  five  participants,  the  necessary  man  years 
of  effort  can  be  accomplished  in  five  years. 

Therefore  the  Committee  appeals  to  the  Workshop  Attendees 
for  increased  participation  in  its  work  to  reduce  this  over- 
all time  period  of  its  project. 
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FIGURE  3 
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FIGURE  4 
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MINUTES  - T Oth  MEETING  OF  THE  PROBLEM  ORIENTED  LANGUAGES  COMMITTEE 
Foxboro,  Massachusetts  Sept  23-24,  1971 
by 

N.  P.  Wilburn 


Attendees: 


P.  Wilburn  - WADCO  Corporation 

D.  Hartmann  - Bailey  Meter  Company 

E.  Bristol  - Foxboro  Company 
R.  Flath  - Leed  s and  Northrup 


Opening  Review 

To  begin  the  meeting  a review  was  made  of  the  minutes  of  the  previous 
POL  Meeting1  and  the  "Summary  of  the  POL  Committee  Activities".2  The 
study  of  this  material  revealed  that,  just  exactly  what,  a POL  should  include, 
was  still  unresolved. 


Characteristics  of  a POL 


The  committee  then  tried  to  answer  the  question  "what  is  the  definition 
of  a POL  and  what  are  its  characteristics",  by  looking  at  three  sources: 

1.  The  POL  Committee  Minutes,  Summary,  etc. 

2.  Vendor  Statements  and  Positions 

3.  The  Attendee's  Understanding 

The  following  observations  were  made  in  this  discussion: 

• The  POL  should  enhance  transfers  of  data  between  sections 
of  the  computer  (as  defined  on  Page  VI-2  of  Reference  2). 

• The  POL  should  be  like  a set  of  tools  that  the  design 
engineer  can  use. 

. The  computer  should  be  transparent. 

• The  POL  is  equated  with  a user  oriented  language  where 
the  user  is  not  a programmer. 

• User  should  be  able  to  set  down  in  a POL,  a solution  to 
his  problem. 

• Transportability  of  programs  that  was  needed  in  the  business 
and  scientific  programs  is  not  required  in  the  POL. 

• But  universality  of  POL's  is  necessary  so  that  retraining 
for  each  user  instance  is  not  required. 


1 "Minutes  - 9th  Meeting  of  the  POL  Committee",  Layfayette,  Indiana,  May  3-6,  1971 

2 "Summary  of  POL  Committee  Activities"  edited  by  P.  Wilburn,  July  1971. 
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In  light  of  the  above  discussion  the  POL  Committee  came  to  the  following 
conclusions  and  concensus: 

• There  cannot  be  just  one  POL  (Concluded  also  in  several 
other  POL  Committee  Meetings) 

• The  POL  should  allow  both  "Fill-in-the-blanks"  type  programs 
and  "sentence"  type. 

• It  seems  an  impossible  (or  at  least  a very  lengthy)  task  to 
meet  both  of  the  above  requirements  in  a committee  situation. 


• Therefore  the  POL  Committee  should  confine  itself  to  describing 
the  basic  architectural  structure  of  the  POL  language(s). 


• Certain  generally  applicable  built  in  functions  should  be 
made  available  in  the  POL  and  the  specifications  for  these 
will  be  made  by  the  committee. 

• The  POL  will  have  the  LTPL  as  its  basis  and  the  POL  will 
accept  into  its  structure  all  of  the  LTPL  definitions 
such  as  character  sets,  etc. 

• The  POL  Committee  acknowledges  the  possibility  of  logical 
inconsistencies  resulting  between  the  POL  and  the  LTPL. 

• The  POL  will  include  on  line  real  time  commands  to  allow 
the  user  to  debug  with  certified  algorithms  or  modules. 


The  most  important  conclusion  made  was: 

•••  The  POL  Committee  will  henceforth  concern  itself  with  defining 
the  structure  of  a "macroing"  capability  to  be  added  to  the  LTPL 
(when  defined).  With  this  structure  it  will  be  possible  to  generate 
many  POL's  all  having  the  same  basic  structure  whose  "sentences'1 
or  "fill-in-the-blanks"  tables  can  be  expanded  into  the  LTPL  (similar 
in  manner  to  macro  expansions  done  in  assembly  languages). 


Macro  Structure 


To  give  the  discussion  a basis,  the  example  POL  statement  suggested  in 
the  sixth  meeting  of  the  POL  Committee  was  again  selected: 

UPDATE  n EVERY  t,  a FOLLOWING  id  START* NG  b TH  SECOND: 

A rough  structure  for  a possible  means  of  defining  the  macro  was  made: 
(underscored  words  are  assumed  to  be  reserved). 
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MACRO  BEGIN 


DECLARE  KEY  STRING  'UPDATE' 

FORMAT  DELIM  (!,'  ')  (2, V) 

TERMINATOR  (;) 

ORDER  KEY,  DELIM(l),  ARG(l),  STRING  'EVERY', 

DELIM(I),  ARG(2) , DELIM(2) , STRING  'FOLLOWING' 
ARG(3) , DELIM ( I ) , STRING  'STARTING', 


ARG(1,  25  CHAR,  NAME) 
ARG(2,  3 DIGIT,  TIME) 
ARG(3, 5 CHAR,  NAME) 


BECOMES 


CALL  System  Prog  #3  (ARG1 , ARG2,  ARG3) 


Where  the  reserved  words  serve  the  following  roles: 


MACRO 


BEGIN 

DECLARE 


FORMAT 

DELIM 

TERMINATOR 


ORDER 


Identifies  macro  and  possibly  changes  meanings  of  some  reserved 
words  from  LTPL  to  POL. 

Beginning  of  Macro 

Declarations  beginning 

Identifies  STRING  which  triggers  macro 

Begins  structural  description  of  macro  calling  sequence 

Specifies  delimiters  to  be  used  in  macro 

Specifies  terminating  character  of  macro 

Specifies  order  of  macro  call 
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STRING 

ARG 

BECOMES 

In 

reached 


Specifies  strings  to  be  used  in  macro  call 

Specifies  arguments  to  be  used  in  macro  call 

Indicates  beginning  of  LTPL  program  into  which  macro  is  to 
be  expanded. 


discussing  this  macro  structure  the  following  conclusions  were 


Deviations  from  the  specified  order  of  the  macro  result  in 
differing  possibilities 

1.  Substitution  of  default  values 

2.  Error  message 

3.  Alternate  code 

The  POL  will  only  allow  deletions  from  the  macro  order  not 
rearrangements  (eg.  deletion  of  "EVERY  t,"  from  example) 

POL  will  have  reserved  words  (eg.  ORDER,  DELIM) 

There  will  be  only  one  type  of  macro  structure 

POL  syntax  will  be  imbedded  in  LTPL  syntax 

Macro  names  will  not  be  used  as  variables 

Communication  between  macro  expansions  at  compile  time  will 
be  made  using  computer  tables 

Conditionals  will  be  allowed  in  the  macro  expansion 
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REPORT  OF  THE  PROBLEM  ORIENTED  LANGUAGES  COMMITTEE 

SEVENTH  WORKSHOP  ON  STANDARDIZATION  OF  INDUSTRIAL 
COMPUTER  LANGUAGES 


The  POL  Committee  met  informally  on  Tuesday  morning  during  thp  Seventh 
Workshop.  The  committee  discussed  the  following  items: 

A.  The  procedures  as  to  how  one  can  obtain  STAGES  should  he 
included  in  the  minutes.  --  STAGE2  or  the  Mobile  Programming 
System  Package  can  be  obtained  upon  request  from 

Graduate  School  Computing  Center 

Univeristy  of  Colorado 

boulder,  Colorado  80302 
The  package  consists  of: 

1.  W.  M.  Waite  - Technical  Report  71-10.  (S3. 00) 

2.  W.  M.  Waite  - Technical  Report  69-2.  ($2.60) 

3.  W.  M.  Waite  - Technical  Report  69-3.  ($4.75) 

4.  U.  M.  Waite  - Technical  Report  69-3B  ($3.40) 

5.  W.  M.  Waite  - "Implementation  Guide  for  Mobile 
Programming  System."  ($2.00) 

6.  026  Card  Deck  for  Mobile  Programming  System.  ($32.00/ 

7.  (Alternate)  Industry  Compatible  7-Track  Magnetic  Tape 
for  Mobile  Programming  System.  ($18.00) 

Approximately  one  month  is  required  between  request  and  receipt 
of  package. 

B.  That  the  POL  Committee  meet  informally  at  each  Workshop  to  review 
current  status  and  whether  the  POL  Committee  should  be  reactivated. 

C.  The  possibility  of  having  another  presentation  to  the  Workshop 
(maybe  on  a fifth  day)  by  vendors  on  the  characteristics  of  their 
particular  POL  or  procedural  language. 

D.  The  possibility  of  presentations  of  user  experiences  with  imple- 
mentation of  STAGE2. 

E.  Copies  of  References  2,  , 5,  6,  7,  and  8 of  the  Bib- 

liography of  these  Minutes  are  included  here. 


r 
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March  6,  1972 


PROBLEM  ORIENTED  LANGUAGES  COMMITTEE  MEETING 

The  next  meeting  of  the  POL  committee  of  the  Purdue  Workshop  on 
Standardization  of  Industrial  Computer  Languages  will  be  Thursday 
and  Friday,  March  23  and  24  in  LaJolla,  California  at  the  Holiday  Inn 
beginning  Thursday  at  9:00  AM. 

Fred  Ruebhausen  has  agreed  to  handle  room  reservations  for  anybody 
who  needs  them.  He  can  be  reached  at  the  following  address  or  phone. 

F.  E.  Ruebhausen 
Control  Data  Corporation 
4455  Eastqate  Mall 
LaJolla,  California  92037 
(714)  453-2500  ext.  325 

As  you  may  have  observed  on  Pages  65  to  75  of  the  last  workshop  minutes 
(attached),  the  direction  of  the  POL  committee's  effort  has  changed 
somewhat.  We  will  be  concerned  for  the  most  part  at  LaJolla  with 
defining  "POLCAT."  I believe  the  following  references  are  pertinent 
to  this  effort  and  it  would  be  helpful  if  you  could  look  at  them  (if 
available)  before  the  meeting. 

1.  "Texas  Instrument  Language  Translator,"  Texas  Instruments, 
Incorporated^ Manual  #955382-9701  (December  1971) 

2.  "A  Language  Independent  Macro  Processor,"  William  M.  Waite, 
Communications  of  the  ACM,  Vol . 10,  No.  7,  July  1967 

3.  "A  Base  for  a Mobile  Programming  System,"  Richard  J.  Orgass 
and  William  M.  Waite,  Communications  of  the  ACM,  Vol.  12, 

No.  9,  September  1969 

4.  "Macro  Instruction  Extensions  of  Compiler  Languages," 

M.  Douglas  Mcllroy,  Communications  of  the  ACM  Vol.  3,  April  1960 

5.  "Syntax  Macros  and  Extended  Translation,"  B.  M.  Leavenworth, 
Communications  of  the  ACM,  Vol.  9,  No.  11,  November  1966 

6.  "Building  a Mobile  Programming  System,"  W.  M.  Waite,  The 
Computer  Journal , Vol.  13,  No.  1,  February  1970 

7.  "The  ML/I  Macro  Processor,"  P.  J.  Brown,  Communications  of  the 

ACM  . Vol.  10,  No.  10,  October  1967 


J 
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A Language  Independent  Macro 
Processor 


William  M.  Waite 

University  of  Colorado*  Boulder,  Colorado 

A macro  processor  is  described  which  con  be  used  with  oJ- 
r.iost  any  source  language.  It  provides  all  features  normally 
associated  with  a macro  facility,  plus  the  ability  to  make  ar- 
bitrary U jnsformations  of  the  argument  strings.  The  program  is 
used  at  the  Basser  Computing  Department,  University  of  Sydney, 
Sydney,  Australia,  to  process  text  for  eight  different  compilers. 


1.  Introduction 

The  term  “macro"  was  first  used  to  denote  a feature  of 
certain  assembly  languages  which  allowed  a programmer 
to  refer  to  a group  of  instructions  as  though  they  were  a 
single  instruction.  By  mentioning  the  name  of  the  “macro- 
instruction,”  the  programmer  caused  all  of  the  component  . 
instructions  to  be  inserted  at  that  point  in  his  coding. 
The  poss.bilitics  of  this  sort  of  redefinition  were  soon 
realized,  and  a classic  paper  by  Mellroy  [1]  showed  how 
an  appropriate  set  of  macro  instructions  could  allow  the 
user  to  tailor  an  assembly  language  to  his  needs  at  a 
quite  high  level.  Until  recently  little  more  was  said  on  the 
subject,  and  most  of  the  operations  proposed  by  Mellroy 
were  used  routinely  in  a number  of  assembly  languages. 
The  problem  of  reprogramming  has  been  responsible  for  a 
resurgence  of  interest,  and  several  papers  [2-5]  have  ap- 
peared during  the  past  two  years. 

One  of  the  significant  features  of  the  current  pajxTs  is 
the  concept  of  a macro  processor  which  is  inde|>cndont  of 
any  particular  assembly  language.  Macro  processing  is 
viewed  as  a type  of  string  manipulation— a character 
stream  fed  to  the  input  is  analyzed  according  to  certain 

This  work  was  performed  at  the  ltasscr  Computing  Depart- 
ment. University  of  Sydney.  .Sydney.  Australia,  ami  was  sup- 
ported by  the  I'.S.  National  Science  Konndation  under  Postdoc- 
toral Research  fellowship  No  1,1070 

• Department  of  Klectrical  Kngmeenng,  University  of  Colorado 


rules,  and  a character  stream  is  produced  as  output.  The 
processor  descrilied  in  this  pu|x*r  is  designed  to  ojxTate  as 
such  a string  manipulator,  and  its  output  is  to  be  presented 
to  some  compiler  or  assembler.  Because  it  can  deal  with 
almost  any  input  text,  it  has  been  named  1.1MB  (/.an- 
guage/ndependent  jl/acro  Processor). 

In  classical  macro  processors  such  as  that  described  by 
Mellroy,  a macro  definition  has  the  form: 

MACRO  NAME  (/>,  , Pi  . • • • , P.) 

Code  body 

END 

Here  the  words  “MACRO”  and  “EXD”  serve  to  delimit 
the  definition,  “NAME”  is  the  macro  name,  and  “ J\ ” 
through  “Pn”  are  formal  parameters.  The  code  body  is  a 
symbol  string  which  may  contain  instances  of  the  formal 
parameters.  The  form  of  a call  on  this  macro  would  be 
“NAME  („4i , As , • • • , -D”  where  k < n.  Such  a call 
is  replaced  by  the  code  hotly  of  the  macro  “NAME”, 
with  the  actual  parameter  strings  At,  -U 

being  substituted  for  the  corresponding  formal  parameters 
Pi , Pi , • • • , Pt  ■ If  k < n,  then  the  processor  generates 
actual  parameter  strings  for  Pt+ 1 , Pt+ .,-  • •,  Pn  in  some 
regular  way. 

Limp  generalizes  the  notion  of  a macro  definition  and 
macro  call.  The  line  which  introduces  a macro  definition 
may  be  any  arbitrary  character  string,  with  parameters 
indicated  by  a special  parameter  symbol.  We  refer  to  this 
line  as  a template.  A template  essentially  allows  the  name 
part  of  a traditional  macro  to  be  replaced  by  a “distributed 
name”  consisting  of  all  portions  of  the  line  other  than  the 
parameter  markers.  This  approach  frees  the  system  from 
any  arbitrary  format  restrictions  of  a particular  language 
— templates  can  be  written  in  a form  suited  to  the  lan- 
guage at  hand. 

Macro  calling  is  accomplished  by  pattern  matching 
against  the  set  of  templates  defined  hy  the  user.  Any 
line  which  cannot  be  matched  is  copied  directly  to  the 
output  without  change.  When  a match  occurs  between  an 
input  line  and  a template,  the  code  body  corresponding  to 
the  template  is  evaluated  with  the  actual  parameters 
resulting  from  the  template  match.  The  result  of  this 
evaluation  replaces  the  matched  line  in  the  output  text. 

Correspondences  between  actual  and  formal  parameters 
are  set  up  during  template  matching.  The  template  is  a 
sequence  of  fixed  strings  separated  by  “holes"  (parameter 
markers).  When  the  matching  process  is  complete,  each 
parameter  marker  will  corres|xmd  to  some  substring  of 
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I tin-  input  line;  the  fixed  strings  of  the  template  will  ex- 

actly match  ntlier  substring*  of  the  line.  The  string 
matched  by  a given  parameter  marker  becomes  Ihc  actual 
parameter  corresponding  to  that  given  formal  parameter. 

The  code  body  of  a l.i.ui*  macro  consists  of  a series  of 
statements  in  a language  almost  identical  to  Sxobol 
[fi,  7].  Formal  parameters  are  specified  by  their  relative 
addresses  in  the  template,  up  to  9 formal  parameters  being 
allowed  per  macro.  (The  relative  address  is  a digit  between 
1 and  9 inclusive,  which  specifies  the  number  of  the 
parameter  marker  in  the  template,  counting  from  the 
left,')  Whereas  conventional  macro  processors  permit  only 
one  form  of  substitution  of  actual  for  formal  parameters, 
Limp  allows  several  alternative  forms.  The  type  of  sub- 
stitution is  specified  for  a given  instance  of  an  actual 
parameter  by  a subscript  on  the  relative  address. 

The  structure  of  Limp  allows  it  to  be  used  as  a pre- 
processor for  almost  any  compiler  or  assembler.  It  was 
incorporated  into  the  KDF9  operating  system  developed 
by  tli?  lhisser  Computing  Department  in  April,  1906  [$] 
and  since  then  lias  been  used  with  programs  written  in 
eight  languages  (three  variants  of  Algol,  two  assembly 
codes,  a list  processor,  a flowcharting  language,  and  an 
autocode).  No  change  in  Limp  is  required  for  any  of  these 
languages. 

The  input  to  Limp  consists  of  a series  of  lines.  (On 
card-oriented  machines  each  card  is  a line;  on  paper  tape, 
lines  are  delimited  by  carriage-return  characters).  The 
first  line  defines  the  set  of  control  characters  for  the  run. 
This  flat/  line  is  necessary  to  preserve  the  language  inde- 
pendence of  the  processor;  different  languages  generally 
require  different  control  characters. 

The  first  character  of  the  flag  line  is  the  end-of-line 
flag.  If  it  appears  on  any  subsequent  line,  its  effect  is  that 
of  a carriage  return — the  remainder  of  the  line  is  ignored 
by  Limp.  This  allows  the  use  of  any  text  as  commentary 
on  any  line.  If  “space”  is  specified  as  the  end-of-line  flag, 
Limp  assumes  that  no  end-of-line  character  is  desired. 

The  second  character  of  the  flag  line  is  the  parameter 
marker.  It  is  only  recognized  as  a control  character  when  a 
template  is  being  entered  into  the  set  of  macro  definitions; 
at  any  other  time  it  is  treated  as  a normal  character.  In 
this  paper,  the  parameter  flag  will  be  represented  by 
and  the  end-of-line  character  by 

After  the  flag  line,  the  user  defines  his  macros.  At  least 
one  definition  must  follow  ihe  flag  line,  and  further  defini- 
tions may  appear  anywhere  in  the  text.  Each  macro  must, 
of  course,  he  defined  before  it  is'  called. 

The  free  format  of  the  input  line  and  the  large  number 
of  templates  involved  create  possible  ambiguities  in  the 
matching  process.  Section  2 describes  the  template- 
matching  algorithm  in  detail  and  shows  how  the  scantier 
resolves  these  ambiguities.  An  informal  specification  of 
the  code  body  statements  can  be  found  in  Section  3, 
where  the  various  types  of  parameter  conversions  are 
defined.  This  section  gives  a brief  review  of  the  features  of 
Snoiiol  which  arc  crucial  to  the  understanding  of  I.imp. 
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In  Section  <1  a number  of  examples  of  Limp  macros  are 
given,  chosen  to  illustrate  the  ba>ic  principle  and  some  of 
the  unique  features  of  the  language.  Section  .">  outlines  the 
construction  of  the  processor  and  gives  an  indication  of 
the  direction  of  future  work  on  this  project. 

2.  Template  Matching 

Matching  a single  template  against  an  input  line  is  a 
special  case  of  the  following  general  problem  [9]:  “Given  a 
pattern  • • • c,|  and  a string  S,  locate  consecutive 
substrings  Si  in  .S’  such  that  each  s,  is  an  acceptable  value 
of  the  pattern  clement  c, .”  Pattern  elements  in  Limp 
templates  arc  either  fixed  strings  or  parameter  flags.  Each 
element  can  be  assigned  a weight,  tr„  equal  to  the  length 
of  the  shortest  acceptable  value  of  e, . If  e,  is  a fixed  string, 
ir,  is  its  length;  if  it  is  a parameter  flag,  w,  = 0 (because 
a parameter  flag  can  match  the  null  string). 

In  general  we  shall  have  a whole  set  of  patterns  which 
are  candidates  for  the  matching  process.  These  patte Vis 
may  be  grouped  into  a tree  with  each  element  correspond- 
ing to  a branch;  the  branches  leaving  a given  node  tan 
then  be  ordered  according  to  the  weights  of  the  corre- 
sponding elements. 

Often  there  may  be  several  ways  for  an  input  line  to 
match  a given  template,  and  a given  input  line  might 
match  any  one  of  several  templates.  For  example,  the  line 
“X  = Y = Z.”  would  match  any  of  the  templates  “*  = 
“X  = “X  = V = and  many  more. 

Moreover,  it  could  match  “*  = in  two  ways:  With 
actual  parameter  1 equal  to  “X  = Y”,  or  with  actual 
parameter  1 equal  to  “X”.  Such  possibilities  complicate 
the  matching  process  and  require  further  specifications  to 
eliminate  ambiguity. 

In  order  to  define  uniquely  which  template  will  match  a 
given  line,  and  which  of  the  possible  matches  to  this 
template  will  be  chosen,  the  following  titles  are  used. 

Rule  1.  A space  which  is  not  adjacent  to  a parameter 
flag  matches  any  nonempty  string  of  spaces,  and  spaces 
at  the  end  of  a line  are  ignored  unless  the  last  character 
of  the  matching  template  is  a parameter  flag. 

Rule  2.  The  matching  process  proceeds  from  left  to 
right  with  each  pattern  element  matching  the  shortest 
possible  substring. 

Rule  3.  At  a node,  matches  are  attempted  for  the 
branches  in  order  of  decreasing  element  weights. 

Rule  4-  If  no  element  at  a node  can  match  a substring, 
then  a new  match  is  attempted  at  the  previous  node. 
Tltis  new  match  is  accomplished  by  extending  the  sub- 
string formerly  matched  to  the  next  shortest  acceptable 
value  for  the  same  element.  If  this  extension  cannot  l>c 
made,  a match  for  the  next  clement  at  that  node  is  at- 
tempted. If  no  element  remains,  rule  4 is  applied  to  that 
node. 

The  pattern  match  succeeds  when  the  last  character  of 
the  input  line  has  been  matched;  it  fails  when  no  match 
can  be  found  for  the  first  character. 
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As  an  example  of  the  matching  process,  consider  the  set 

of  templates 

(1)  SAM  = A. 

(2)  SAM  = *. 

(3)  • = .. 

(4)  * = A. 

(5)  •=•=*. 

The  tree  for  this  set  is  shown  in  Figure  1,  where  a lower 
case  “b”  is  used  to  denote  a space. 


TABLh  I.  Si'Hixo  N'.ivt.i  Available  in  Limp 


SAMb=b 


-= (2) 


■b--b-— * — • - (5) 


Fig.  1.  An  example  of  a template  tree 

The  input  line  “SAM  = A.”  will  match  template  (1), 
as  will  any  line  which  has  a nonempty  string  of  spaces 
between  “SAM”  and  “ = ” or  between  “ = ” and  “A.”. 
The  effect  of  Rule  1 is  thus  to  make  a string  of  spaces 
significant,  but  the  exact  number  of  spaces  in  the  string 
is  immaterial.  (When  a template  is  read  and  merged  with 
the  tree  any  string  of  spaces  is  replaced  by  a single  space.) 

Suppose  that  the  next  two  input  lines  were  “SAM  = 
B.”  and  "SAM  = C.’\  where  there  are  six  spaces 

between  “ = ” and  "C”  in  the  second  line.  Both  lines  match 
template  (2),  and  in  the  first  line  the  value  of  the  actual 
parameter  will  l>e  "B”.  In  the  second  line,  however,  the 
value  of  the  actual  parameter  will  be  “ C” — five  of 

the  six  spaces  have  been  included  in  the  actual  parameter. 
This  is  because  the  space  in  template  (2)  between  “ = ” 
and  is  adjacent  to  a parameter  Hag:  A space  adjacent 
to  a parameter  flag  matches  exactly  one  space,  so  that 
the  remaining  spaces  must  be  absorbed  by  the  parameter. 
No  spaces  are  actually  deleted  from  the  input  line  during 
the  matching  process,  so  that  if  no  match  is  found  all 
spaces  arc  preserved  when  the  string  is  written  out. 

At  first  glance  one  nnght  assume  that  the  input  line 
“B  = C ~ A.”  would  match  template  (4)  with  “B  = C” 
as  the  value  of  the  actual  parameter.  Consideration  of 
the  rules  will  show,  however,  that  this  line  will  be  matched 
to  template  (.*>). 

The  crucial  decision  occurs  at  the  second  node  of  the 
lower  trunk  of  the  tree  At  this  [Hiint  we  have  matched 
“B”  to  the  first  parameter  Hag  and  "!>  = b“  to  the  fixed 
portion  of  the  template,  as  required  by  Rule  2 (“B"  is  the 


Nome 

Function 

dc 

i Hctual  parameter  d,  conversion  c 

U < d < »,  1 < c < 3) 
Oi 

1 

current  value  of  location  counter, 

(1  < * < 9) 

minus  t 

IN 

effective  input  line 

PR 

printing  output  stream 

PU 

punching  output  stream 

PT 

private  tree 

ST 

symbol  tree 

TT 

template  tree 

shortest  possible  matching  substring  for  the  first  parame- 
ter). According  to  Rule  11  the  next  match  to  be  attempted 
must  be  for  “A.”. 

The  match  for  “A.”  fails  because  the  next  character  of 
the  line  is  “C”.  So  we  attempt  a match  for  the  parameter 
flag.  Now  the  only  way  in  which  we  can  extend  the  match 
for  the  first  formal  parameter  is  by  repeated  use  <>!  Rule  4. 
But  this  requires  that  we  he  unable  to  find  nny  match 
at  all  nodes  further  along  the  branch.  Since  the  line 
matches  template  (5),  we  will  not  get  the  chance  to  apply 
Rule  4 at  all. 

3.  Code  Body 

When  Limp  matches  an  input  line  to  a temolate,  it 
creates  actual  parameter  strings  and  then  execute:  a series 
of  statements  making  up  the  code  body  of  tin  macro. 
The  statements  of  the  code  body  are  written  in  a language 
which  is  almost  identical  in  form  to  Snoboi..  There  are  two 
reasons  for  this  choice:  (1)  The  operations  available  in 
Snoboi.  allow  very  general  manipulations  of  the  actual 
parameters.  (2)  The  syntax  of  Sxobol  effectively  sepa- 
rates the  metacharacters  from  the  strings  being  manipu- 
lated and  thus  preserves  the  language  independence  of 
the  processor. 

The  general  form  of  a statement  in  the  code  body  of  a 
Limp  macro  is: 

dabelKstringXpattend  = (replacement)/(go-to/ 

As  in  Snoboi.,  a statement  label  must  begin  in  the  l ist 
character  position  of  the  line  and  may  consist  <>f  any 
string  of  letters  or  digits.  The  lal>cl  terminates  at  the 
first  space;  if  the  first  character  of  the  line  is  a space,  U is 
assumed  that  the  statement  has  no  label.  The  next  con- 
stituent of  the  statement  is  a string  reference.  In  Snoboi. 
a string  may  be  given  almost  any  symbolic  name,  but 
in  Limp  the  programmer  may  use  only  a fixed  set  of  names 
as  summarized  in  Table  I.  The  only  strings  which  may 
be  used  as  working  storage  during  the  execution  of  a code 
body  are  those  corresponding  to  the  nine  |»ossible  actual 
parameters.  System  strings  (such  as  IN)  have  special 
projicrties  which  disqualify  them  lor  use  as  working 
storage.  The  private  tree  (1’T)  can  lie  used  to  store  inlet 
mediate  results  when  more  than  nine  strings  are  needed. 
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II.  P.vnnu.x  tl 

n.Mi..vr»  Accfc.PTKn  bv  la  up 

J'vpe 

Format 

Matches 

lateral 

‘any  siring’ 

itself 

Pimsiant 

dc 

a substring  containing  the  same 

I 

(0  < d < 9, 

characters  as  the  specified 

t 

0 < c < 9) 

constant  siring. 

Arbit  rary 

dA 

i any  string  or  substring,  includ- 

1 

ing  the  mill  string 

Balanced 

dll 

| a non-void  string  which  is 

i 

! balanced  with  respect  to  ( ) 

Fixed- 

dFk 

j any  string  of  length  h (k  may 

length 

be  any  number  of  digits i 

Back- 

dR 

! the  string  which  was  previously 

referenced 

| matched  to  variable  d 

Essentially  this  tree  constitutes  the  "backup  store”  for 
the  macro  processor;  it  is  used  only  by  code  bodies  and  is 
nexter  altered  by  any  part  of  the  system. 

'.'lie  third  constituent  of  the  statement,  the  pattern, 
may  be  absent.  If  present,  it  consists  of  a scries  of  pattern 
elements  separated  by  blanks.  The  allowed  pattern  cle- 
ment' are  listed  in  Table  II.  When  a literal  string  is  read, 
the  procedure  for  handling  quotes  is  as  follows:  The  first 
quote  marks  the  beginning  of  the  literal.  Any  subsequent 
string  of  n consecutive  quotes  is  replaced  by  a string  of  k 
consecutive  quotes,  where  k is  the  greatest  integer  not 
greater  than  n 2.  If  there  is  a nonzero  remainder  from 
tin-  division,  the  literal  terminates.  A literal  may  extend 
over  several  lines,  in  which  case  a carriage  return  charac- 
ter i-  inserted  in  the  literal  at  the  end  of  each  line.  This 
allows  the  programmer  to  write  a single  literal  which  pro- 
duces several  lines  of  output. 

If  a pattern  is  specified  in  a statement,  the  pattern  is 
tested  against  the  string  named  by  the  string  reference. 
If  the  pattern  can  be  matched  to  some  substring  of  the 
string  refereuee,  strings  are  created  for  each  variable  in 
the  pattern.  Also,  the  matching  substring  may  be  altered 
In  -pecifying  a replacement.  This  replacement  may  con- 
tain t lie  variables  defined  by  the  pattern  match;  see  [6,  7] 
for  further  details.  Note  that  if  no  replacement  is  desired, 
both  the  " = ” and  the  replacement  string  should  be 
omitted.  If  " = ” is  present  but  no  replacement  string  is 
specified,  the  null  string  is  assumed. 

A 'tatement  may  stretch  over  several  lines.  If  the  line 
changes  occur  within  a literal,  they  result  in  carriage 
return  characters  as  noted  above.  If  they  fall  between 
the  constituents  of  the  statement,  they  are  treated  as 
spaces.  Constituents  must  be  separated  by  at  least  one 
space  or  carriage  return,  and  additional  spaces  or  carriage 
returns  are  ignored.  The  •*/”  preceding  t lie  go-to  field 
must  lie  present  whether  the  go-to  is  used  or  not — it 
serves  notice  that  the  current  line  is  the  last  one  for  the 
current  statement. 
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The  go  to  field  may  he  absent,  but  if  present  it  takes  one 
of  the  following  forms: 

((label))  — transfer  control  to  (label)  unconditionally 
S((lubel>)  — transfer  ronirol  to  (luUd/  if  the  pattern  match  was 
successful 

F((labcl))  — transfer  control  to  (label)  if  the  pattern  match  waa 
not  successful. 

Both  conditional  jumps  may  be  present,  in  either  order. 
Spaces  are  ignored  everywhere  in  the  go-io  field. 

A code  body  may  contain  any  number  of  statements, 
the  last  of  which  is  distinguished  by  the  label  “END”. 
This  last  statement  need  not  contain  any  other  constit- 
uents, including  the  slash.  Of  course  it  may  ;ilso  be  a nor- 
mal code  body  statement,  in  which  both  the  slash  and 
string  reference  are  required. 

The  conversion  digits,  denoted  by  “c”  in  Table  I, 
describe  the  way  in  which  the  actual  parameter  string  is 
to  be  used  in  each  particular  substitution  instance.  The 
meanings  of  these  digits  are  (1  < d < 9): 


d0  — use  an  exact  copy  of  the  actual  parameter  string, 
dl  — use  an  exact  copy  of  the  actual  parameter  string;  if  this 
conversion  appears  in  a string  reference,  any  pattern  speci- 
fied must  match  a substring  which  begins  at  the  first  charac- 
ter of  the  referenced  string.  (This  is  equivalent  to 
“anchored  mode”  in  Snobol.) 

d2  — look  up  the  string  on  the  symbol  tree  and  use  the  value 
found;  if  the  string  is  not  in  the  symbol  tree,  use  a null 
string. 

d3  — same  as  d2,  except  that  if  the  string  is  not  found,  it  is  added 
to  the  symbol  tree  and  given  the  current  value  of  parameter 
0 (the  “location  counter”).  Parameter  0 is  incremented  by 
one  following  this  definition. 

The  symbol  tree  is  established  cither  by  the  use  of  type 
3 parameter  calls  or  by  direct  action  on  the  part  of  the 
programmer.  The  symbol  tree  has  the  name  ST,  which 
can  be  used  as  the  string  reference  in  any  statement.  Some 
caution  must  be  exercised,  however,  because  SI'  is  a tree 
rather  than  a string.  The  pattern  must  begin  with  a set 
of  constant  elements.  This  constant  portion,  consisting 
of  all  elements  up  to  the  first  variable,  will  be  tested  against 
the  tree  and  must  match  some  entry  all  the  way  from  the 
root  to  a leaf.  The  remainder  of  the  pattern  will  bt  tested 
in  the  usual  way  against  the  string  attached  to  tfie  leaf. 
Any  replacement  will  only  be  made  to  that  part  of  the 
pattern  which  is  beyond  the  leaf.  This  constraint  allows 
the  programmer  to  change  the  definition  of  a symbol, 
but  not  to  delete  a symbol  from  the  tree.  The  entire  tree 
may  be  deleted  by  “ST  = /”,  and  a symbol  may  be  added 
by  “ST  = ST  (specification  of  symbol)/”.  If  the  added 
symbol  is  to  be  defined,  a second  statement  must  be  used. 

The  system  maintains  a location  counter  which  the  pro- 
grammer can  use  in  several  ways:  (1)  Type  3 conversion 
can  he  used  to  assign  the  current  value  of  the  location 
counter  to  a symbol.  The  location  counter  is  automatically 
incremented  bv  1 following  the  assignment.  (2)  A set  of 
local  labels  can  be  obtained  by  using  parameter  0 ex- 
plicitly. A reference  to  string  Oi  is  taken  as  the  current 
value  of  the  location  counter  minus  i.  If  the  programmer 
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uses  such  constructions,  he  is  responsible  for  incrementing 
the  location  counter  by  the  maximum  value  of  /,  plus  1, 
before  the  first  suei;  reference  is  encountered.  This  can  be 
done  by  the  statement  “00  = (00  + 'i'  + '1')/”. 

As  shown  iti  the  statement  above,  integer  arithmetic 
can  be  jierformed  on  strings  in  Limp.  Each  expression  is 
enclosed  in  parentheses  and  has  as  its  value  a string  con- 
taining the  numeric  value  of  the  expression.  The  allowed 
operators  are  +,  — , * and  /,  with  their  usual  meanings. 
Note  that  there  is  no  possibility  of  confusion  between 
“/”  used  as  an  end-of-statement  mark  and  “/”  used  as  a 
division  operator  because  the  latter  appears  only  within 
parentheses.  Parentheses  may  be  nested  to  arbitrary  depth, 
and  arithmetic  operations  may  continue  over  as  many 
lines  as  necessary.  Numbers  are  stored  as  strings  of  digits; 
negative  numbers  are  signed,  positive  are  not. 

4.  Examples  of  LIMP  Macros 

The  simplest  possible  macro  operation  is  one  in  which  t. 
single  line  is  expanded  into  several  lines  with  parameter 
substitution.  For  example,  suppose  we  wish  to  write  an 
arithmetic  statement  in  an  assembly  language  program  on 
a single  address  machine  (the  notation  for  this  assembly 
language  i>  that  of  [1]): 

• = • + •. 

END  IT  - 'FETCH,  ' 20  ' 

ADD  ' 30  ' 

STORE, ' 10  / 

This  template  would  match  a line  such  as  “SAM  = JOE 
+ HILL.”,  and  the  code  body  would  punch: 

FETCH.  JOE 
ADD.  HILL 
STOUE,  SAM 

The  system  string  "PI*”  is  the  punch  unit,  and  whenever 
it  is  assigned  a value,  that  value  is  punched  (followed  by  a 
carriage  return’).  "PH”  is  the  printer,  and  behaves  in  the 
same  way.  The  intermediate  carriage  returns  were  supplied 
by  including  them  in  literals. 

The  next  step  in  complexity  is  to  allow  a macro  call  to 
lie  used  in  the  code  body  of  another  macro.  For  example, 
we  might  define  a complex  addition  by: 

Z*  “ z*  + z*. 

IX  'R'  10  1 = It'  20  ' + R'  30  / 

END  IX  = T 10  ' - I'  20  ' + I'  30  / 

If  the  line  which  was  matched  was  “ZSAM  = ZJOE  + 
SHILL.”,  then  the  first  statement  would  assign  the  value 
"HSAM  = H.IOE  + RH1LL.”  to  the  system  string  IX. 
(Note  that  the  end  of-litic  symbol  is  automatically  sup- 
plied.) The  effect  of  this  assignment  is  to  save  the  current 
state  of  all  strings  and  call  the  processor  recursively  to 
expand  the  line  whose  value  is  assigned  to  IN.  After  the 
expansion  is  completed,  control  returns  to  the  next  statc- 
nent.  If  IN  is  used  in  a pattern  or  replacement,  rather 
pian  living  assigned  a value,  its  value  is  the  next  effective 
input  line  (an  effective  input  line  may  have  been  gener- 
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ated  by  a macro  at  a higher  level,  as  “HSAM  •••”  in 
the  present  example). 

In  most  eonventional  macro  processors,  an  expanded 
line  is  automatically  submitted  for  a re-sean;  i i I.i.ui* 
t lie  re-scan  is  under  the  control  of  the  programmer,  l or 
most  applications  this  causes  no  difficulty,  hut  litre  are 
certain  macros  in  which  the  programmer  may  u<  t know 
whether  a line  contains  a macro  call  or  not.  In  such  in- 
stances he  would  resubmit  the  questionable  line  to  Li.ut’ 
by  assigning  it  to  IN'.  If  it  matched  some  template,  it 
would  be  expanded;  otherwise  it  would  merely  be  copied 
into  the  punch  output  stream. 

All  of  the  normal  conditional  assembly  operations  of 
most  macro  generators  are  available  in  Limp  by  means  of 
suitable  statements.  We  cun  easily  test  the  value  of  any 
argument,  make  arbitrary  changes  in  any  argument,  skip 
statements,  loop,  etc.  The  only  feature  of  conventional 
macro  processors  which  is  not  obviously  available  is  that 
of  nested  definition.  This  is  provided  by  explicit  reference 
to  the  template  tree  by  means  of  the  symbol  "TT”.  Statc- 
ments  using  TT  obey  exactly  the  same  rules  as  those  using 
ST,  the  symbol  tree.  Suppose,  for  example,  that  we  were 
writing  an  algebraic  language  based  on  single-address 
assembly  code.  Suppose  further  that  we  demanded  that 
the  programmer  declare  all  variables.  We  could  define  a 
macro  to  inform  him  of  undeclared  variables: 

FETCH,  ♦. 

END  PR  = 'VARIABLE  ' 10  ' IS  UNDECLARED.'/ 

The  addition  macro  defined  above  would  be  altered  to 
expand  the  FETCH  instruction  (using  IN),  rather  than 
just  punching  it,  and  this  would  cause  the  "L'i  declared” 
message  to  be  printed: 

• = • 4"  *■ 

IN  - 'FETCH,  ' 20  / 

END  PC  = 'ADD,  ' 30  ' 

STORE,  ' 10  / 

Now,  whenever  a variable  is  declared,  we  must  define  a 
FETCH  macro  for  that  variable.  The  template  matching 
process  ensures  that  the  macros  containing  variable  names 
will  take  precedence  over  the  one  with  a parameter  (lag. 
VARIABLE  .. 

PU  = 10  ':  RESERVE,  l'  / 

TT  = TT  'FETCH,  ' 10  / 

END.TT  'FETCH,  ' 10  = 'IT  - "FETCH, ' 10  '"  / 

END'  / 

The  first  statement  punches  an  assembly  code  O|x>rutiou 
to  reserve  one  location  for  the  variable  and  define  the  sym- 
bol. The  second  statement  inserts  the  new  template  mi  TT, 
while  the  third  provides  the  definition.  Note  bow  the 
quotes  in  the  definition  are  supplied  since  they  are  in 
side  a literal,  their  number  must  be  doubled.  The  slash 
on  the  third  line  is  a part  of  the  literal,  not  the  tormina 
tion  of  the  rule.  The  FETCH  macro  for  the  variable  A 
would  thus  have  the  form: 


FETCH,  A 
1T  - 'FETCH,  A'  / 
END 
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Xotieo  here  that  the  use  of  FETCH  as  both  a macro  name 
ami  a target  language  operation  is  possible  because  of  the 
programmer’s  freedom  to  submit  a line  for  re-scan  or 
punch  it  out  immediately. 

'I'lte  biain  reason  for  requiring  that  the  programmer  de- 
clare his  variables  in  the  preceding  example  was  to  ensure 
that  spaec  was  reserved.  This  can  be  done  using  the  Limp 
symbol  tree  and  type  3 conversion  without  requiring 
declarations.  Instead  of  defining  the  fetch  macro  to  print 
an  “Undeclared"  message,  we  write: 

FETCH,  .. 

END  PU  = ’FETCH,  V+’  13  / 

By  the  definition  of  type  3 conversion,  this  macro  will 
punch  out  “FETCH,  V -+-  n”  where  “n”  is  the  value  found 
in  the  symbol  tree  for  the  variable.  If  the  variable  was  not 
in  the  symbol  tree,  it  would  be  added  and  given  the  current 
value  of  the  location  counter.  The  location  counter  would 
then  be  incremented  by  one. 

At  the  end  of  the  program,  we  would  reserve  a block  of 
space  to  hold  all  variables.  A little  thought  will  show  that 
the  si/e  of  this  block  is  just  the  value  of  the  location  coun- 
ter at  the  end  of  the  program.  We  can  therefore  define  a 
macro1  END  by: 

END. 

ENI)  PU  = ’V:  RESERVE.  ’ 00  ’ 

END’  / 

This  macro  will  replace  the  programmer’s  END  statement 
with: 

V:  RESERVE,  k 

END 


definitions  or  change  them  tcmjiorarily.  The  statement 
TT  (constant  pattern)  il A = (string)  <10/ 

will  add  code  to  an  existing  macro.  We  can  change  a macro 
temporarily  by  something  like: 

TT  ’TEMPLATE  .’  tlA  = (string)  / 

PT  = PT  'SAVEMAC1  / 

PT  ’SAVEMAC’  = <10  / 

The  current  code  body  of  macro  “TEMPLATE  *”  is 
saved  on  the  private  tree  as  the  value  of  the  symbol 
“SAVEMAC”,  and  is  replaced  on  the  template  tree  by 
(string).  The  code  body  can  be  recovered  from  the  private 
tree  by: 

PT  ’SAVEMAC’  dA  = / 

TT  ’TEMPLATE  .’  = 40/ 

In  the  current  version  of  Limp  the  code  body  of  a macro  is 
not  held  as  a string  because  of  the  consequent  slowdown 
in  interpreting  it.  It  is  converted  into  a list  structure  when 
first  defined,  and  hence  it  is  not  possible  to  use  string 
operations  to  make  changes  icithin  the  code  body.  If  such 
operations  are  necessary,  the  code  body  must  be  entered 
by  means  of  “IX”  and  stored  on  the  private  tree  as  a 
string.  Changes  can  then  be  made,  and  the  code  body 
redefined  from  this  string.  The  following  macro  will  read  a 
code  body  and  store  it  in  the  private  tree  as  a string: 

ENTER  CODE  BODY  . UNTIL  .. 

PT  = PT  10  / 

30  = / 

LINE  tO  = IN  / 

41  20  /S(END) 

30  = 30  40  /(LINE) 

END  PT  10  = 30  / 


! 


A call  on  this  macro  might  be: 


This  reserves  a block  of  memory  of  the  current  length 
and  gives  it  the  name  V.  The  assembler’s  address  arith- 
metic feature  then  references  each  variable  within  this 
block. 

Suppose,  however,  that  the  assembler  being  used  can- 
out  do  address  arithmetic.  Limp  macros  can  still  be  written 
to  avoid  the  need  for  variable  declaration: 

FETCH,  .. 

END  PU  = ’KETCH,  V’  13  / 

END. 

10  = 00  ’.’/ 

20  = ’O’  / 

Cl  IK  11  20  ’.’  /S(END) 

PU  = ’V’  20  ’ : RESERVE,  1’ / 

20  = (20  + T)  /(CHK) 

END  PU  = ’END’  / 

Here  each  variable  is  named  “Vi”  for  successive  integers  i. 
The  "END”  macro  then  creates  a seris  of  space  reserva- 
tions, one  for  each  variable.  It  is  interesting  to  note  that 
there  is  no  penalty  attached  to  specifying  a go-to.  Because 
nf  the  way  the  statements  are  stored,  one  with  no  go-to 
Iteld  is  effectively  supplied  with  two  go-to’s.  both  to  the 
succeeding  statement. 

The  use  of  TT  allows  us  to  add  code  to  existing  macro 


ENTER  CODE  BODY  SAM  UNTIL  SAM  IS  FINISHED 
(code  body) 

SAM  IS  FINISHED. 

The  code  body  would  be  read  and  stored  in  actual  parame- 
ter 3 until  the  line  “SAM  IS  FINISHED”  was  recognized 
by  the  test  “41  20  /S(EXD)”.  At  this  point  the  string  from 
parameter  3 would  be  stored  as  the  value  of  “SAM"  on 
the  private  tree.  This  string  could  then  be  manipulated 
in  any  way  and  defined  as  the  code  body  of  any  template. 


5.  Implementation  ami  Extension 

The  entire  Limp  processor  is  written  in  the  list  language 
Wisp  [10,  11],  and  hence  possesses  a certain  amount  of 
machine  as  well  as  language  independence  (Wisp  systems 
are  available  on  the  IBM  7094,  7010.  GIC  20.),  English 
Electric  KD19,  Elliot  N03,  F.dsac  2 and  Atlas  2).  The 
processor  itself  is  imbedded  in  an  environment  which 
interacts  with  the  operating  system  to  route  Limp  output 
text  to  the  correct  compiler.  In  the  Basscr  system,  the 
compiler  to  be  used  is  specified  by  3 characters  of  a 12- 
charaeter  program  identifier.  The  user  may  provide  a pro- 
gram title  as  well  as  an  identifier,  and  the  Limp  environ- 
ment uses  the  first  3 characters  of  this  title  to  replace  the 
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compiler  specification.  The  output  text  from  Limp  is 
then  resubmitted  to  the  system  by  writing  it  on  a magnetic 
tape  and  resetting  the  input  unit.  There  is  no  restriction 
on  the  compiler  selected;  it  could  easily  be  Limp  again. 
It  is  therefore  possible  to  make  multiple  passes  through 
Limp  before  going  to  a conventional  compiler. 

The  version  of  Limp  described  in  this  paper  is  a reformu- 
lation of  that  which  is  currently  in  use  in  the  Basser  Com- 
puting Department.  The  two  versions  are  equivalent  in 
power,  but  the  Basser  version  requires  that  the  code  bodies 
be  written  out  in  a form  much  closer  to  that  in.  which  they 
are  executed.  The  resulting  macro  definitions  are  relatively 
clumsy  to  write,  and  difficult  to  decipher  when  debugging. 

The  processor  has  two  main  phases:  definition  and  ex- 
pansion. When  a macro  is  defined,  its  template  is  added 
to  the  template  tree  and  its  code  body  is  converted  into  a 
form  .which  can  be  handled  by  an  interpretive  routine 
during  the  expansion  phase.  This  conversion  recognizes  a 
number  of  special  eases,  and  sets  up  different  structures 
for  each.  Tor  example,  if  “PU”  is  the  string  reference, 
t ten  the  replacement  is  formed  into  a single  string  with 
markers  for  the  parameter  substitutions.  Thus  the  string 
need  not  be  re-evaluated  each  time  the  macro  is  expanded. 
Successive  punch  statements  are  combined,  with  suitable 
insertion  of  carriage  return  characters.  Similar  simpli- 
fications can  be  made  where  the  string  reference  is  “PIl” 
or  “IN”.  Statement.'  referencing  “PT”,  "ST”  and  “TT” 
are  likewise  sinaied  out  and  when  a symbol  or  template 
is  defined  by  means  of  two  such  statements,  these  are 
combined. 

During  the  expansion  phase,  input  lines  are  read  and 
matched  to  the  template  tree.  When  a macro  call  is  found, 
tnc  corresponding  code  hotly  is  examined  and  one  of  sev- 
eral processors  i>  called  to  punch,  print,  move  information 
to  the  input,  etc.  One  of  these  processors  is  an  interpreter 
for  the  subset  of  Snobol  which  makes  up  the  general 
code  body  statement.  If  the  statement  cannot  be  recog- 
nized as  a special  case,  it  is  handled  by  this  interpreter. 
Kach  such  statement  has  been  converted  into  a list  with 
subh.sts  for  the  pattern  and  replacement,  each  of  which 
is  a list  of  elements.  The  go  to  fields  are  replaced  by  links 
to  the  lists  for  the  correct  statement.  If  no  go-to  is  speci- 
fied. both  S and  1 links  point  to  the  next  sequential  rule. 
Thus  even  rule  effectively  has  go  to  fields,  and  any  rule 
which  is  not  accessible  from  some  other  rule  is  not  at- 
tached to  the  list  structure.  Such  inaccessible  rules  are 
eliminated  during  garbage  collection. 

Limp  enters  the  definition  phase  immediately  after 
processing  the  flag  line,  and  accepts  definitions  until  a 
blank  line  is  encountered  where  a template  is  expected. 
The  expansion  phase  is  entered  with  the  succeeding  line. 
(Notire  that  tfi.<  allows  for  a blank  line  to  appear  any- 
where within  a rode  body.)  The  expansion  phase  continues 
until  one  of  the  three  statements  “TT  = IN  ”,  “I’U  = 
IN'  /”  or  "PH  = IN’  ” is  executed  in  a code  body.  The 
first  statement  initiates  a re-entry  to  the  definition  phase. 


When  another  blank  line  is  found,  the  program  return 
to  the  statement  following  “TT  = IN  ”,  The  two  Male 
ments  “PU  = IN'  /”  and  "l’H  - IN  ’’  initiate  blocs 
copying  from  the  input  unit  to  the  punch  and  printer, 
respectively.  In  each  case  the  template-matching  pro -ess 
is  bypassed.  When  a blank  inn  is  encountered,  the  proc 
essor  returns  to  the  statement  following  the  one  which 
initiated  the  copying. 

The  major  drawback  of  the  current  implementation 
is  that  Wise  stores  a single  character  |>er  word,  ulich 
increases  both  the  storage  requirements  and  execution 
times  of  Limp.  When  it  is  processing  macro-  with  man\ 
statements  which  are  not  special  cases,  the  name  “Limp” 
seems  particularly  apt.  This  defect  of  Wisp  i.»  being  rein 
edied  by  the  inclusion  of  packed  character  string-  a-  data 
items. 

The  major  extension  contemplated  for  Limp  is  an  al- 
teration of  the  template  scan.  It  is  pro|>osed  that,  instead 
of  a single  parameter  flag,  we  allow  named  parameters 
of  the  form  *NAME*.  Such  a parameter  would  be  de- 
fined by  a Backus  Normal  Form  expression,  and  the  .-<  m 
ner  would  have  the  power  of  a syntax-directed  compiler: 
A substring  of  the  input  line  would  only  match  a mimed 
parameter  if  it  had  the  specified  syntax.  Each  BNT  rule 
would  have  an  associated  code  body,  which  would  be 
called  by  a function  EX(dO).  The  value  of  this  function 
would  be  the  string  produced  bv  the  code  body  of  the  rule 
used  to  recognize  parameter  il.  A parameter  with  no  mime 
(i.e.,  “**”)  would  be  handled  in  the  same  way  a»  the  cur- 
rent version  handles  all  parameters.  The  extended  Limp 
would  be  closely  related  to  the  syntax-directed  compiler 
described  by  Warshall  and  Shapiro  [12]. 

Extending  Limp  in  the  manner  described  above  would 
result  in  a program  with  considerable  power,  but  which 
could  be  used  for  simple  things.  One  of  the  drawbacks  of  a 
syntax-directed  compiler  is  that  one  must  specify  the  en- 
tire syntax  of  a language.  This  would  not  be  the  ease  in 
extended  Limp.  One  could  make  small  changes  m the 
apparent  behavior  of  an  existing  compiler  by  definimr 
small  extensions  or  changes  in  its  syntax  in  Limp-  the 
bulk  of  the  syntax  analysis  would  still  be  done  by  the  ex 
isting  compiler. 

A macro  processor  which  has  this  ability  to  make  ■■'mil! 
changes  in  an  existing  compiler  was  recently  described  by 
Leavenworth  [13].  Ilis  program  uses  syntactic  informal  ion 
during  the  recognition  process  and  allows  fixed  siring-;  to 
be  interspersed  with  the  formal  parameters.  However, 
the  macro  name  must  precede  the  first  parameter  and 
must  be  unique.  Apparently  recognition  of  the  macro  is 
performed  on  the  basis  of  the  name  alone,  and  syntactic 
information  is  used  solely  to  establish  the  values  of  the 
actual  parameters.  The  code  body  of  the  macro  allows 
for  conditional  generation  in  a rather  restricted  manner. 
By  including  extra,  information  in  the  template  ((ollmritiq 
the  name)  one  macro  definition  essentially  become'  sev- 
eral. The  code  body  then  has  ways  of  generating  appro- 
priate code  for  each  alternative. 
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6.  Summary 

In  this  paper  we  haw  tlfserilxxl  an  approach  to  laii- 
guaiiciiulepctitloin  macro  processing,.  The  key  principle  of 
limp  is  string  manipulation  with  parameter  substitu- 
tion. a technique  which  lias  recently  been  used  in  two 
similar  processors;  Strachey’s  (ieneral  Purpose  Muero- 
Keneralor  pi]  and  Mixicrs’  Tkac  (">].  These  systems  are 
very  close  to  Limp  in  design  goals,  but  their  realization 
displays  a fundamental  difference  in  programming  philoso- 
phy. Both  employ  the  notion  of  “nested  functional  ex- 
pressions” in  which  the  macro  is  written  as  a composite 
function  with  strings  as  arguments.  Limp  treats  the  macro 
as  a procedure  to  be  executed  rather  than  a function  to  be 
evaluated. 

Limp  has  sufficient  capacity  to  provide  the  programmer 
with  a powerful  tool  for  modifying  the  apparent  behavior 
of  an  existing  compiler,  without  the  necessity  for  a com- 
plete redefinition  of  that  compiler’s  language.  This  pro- 
gram has  boon  available  for  general  use  in  the  Basser 
Computing  Department  since  April,  1966.  Typical  appli- 
cations have  been  to  reduce  the  amount  of  punching  re- 
quired in  Algol  programs,  to  eliminate  the  need  for  many 
of  he  line  declarations  in  a flowchart  language,  and  to 
avtid  the  individual  specification  of  large  numbers  of 
constants  in  plotting  programs  written  in  assembly  code. 

Our  experience  with  Limp  has  led  us  to  consider  the 
possibilities  of  incorporating  most  of  its  features,  into  a 
general  text -editing  system,  thus  combining  the  tasks  of 
text  correction  and  expansion.  Research  in  this  area  is 
being  carried  out  in  connection  with  the  development  of  a 
multicomputer  network  by  the  staff  of  the  Basser  Com- 
puting Department. 

Ail:notcM<inietU.  The  general  approach  taken  by 
Limp  is  similar  to  that  of  most  other  macro  processors — 
its  relation  to  Befap  and  Ihmap  can  easily  be  seen.  Many 
features  of  Limp  are  a direct  outgrowth  of  the  author’s 
work  on  several  Wisp  compilers,  in  collaboration  with 
Prof.  M.  V.  Wilkes  (Univ.  of  Cambridge),  H.  Schorr 
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(IB.M),  and  II.  .1.  Orgass  (Vale  Univ.).  Special  thanks  are 
due  to  Dr.  M.  11.  Ralhgeber  of  the  University  of  Sydney 
for  his  aid  in  providing  test  cases  and  suggestions  for  both 
the  processor  and  its  documentation,  and  to  the  two 
referees  who  struggled  through  the  first  version  of  this 
paper  and  provided  an  all-important  fresh  outlook. 

Received  May,  1066;  revised  November,  1067 

REFERENCES 

1.  McIlroy,  M.  D.  Macro  instruction  extensions  of  compiler 

languages.  Comm.  ACM  S (April,  1000),  214. 

2.  Halpekn,  M.  I.  XPOP:  a metalanguage  without  meta- 

physics. Proc.  AKIPS  1064  Fall  Joint  Comput.  Conf .,  Yol.  26, 
p.  57. 

3.  Strachey.  C.  A general  purpose  macrogenerator.  Comput.  J . 

a (Oet.  1065),  225. 

4.  Graham,  M.  I„,  and  Ingehman,  P.  Z.  An  assembly  language 

for  reprogramming.  Comm.  ACM  8 (Dec.  1005),  782. 

5.  Mooers.  C.  X.  TliAC,  a procedure-describing  language  for 

the  reactive  typewriter.  Cumin.  ACM  9 (March.  1906),  215. 

6.  Farber,  D.  J.,  Griswold,  It.  E.,  and  Polonsky,  I.  P. 

SXOBOL,  a string  manipulation  language.  J.  ACM  11 
(Jan.  1964),  21. 

7.  . The  SXOBOL3  programming  language.  BSTJ  SS 

(July-Aug.  1 966 ) , p.  895. 

8.  Waite,  W.  M.  A language-independent  macro  processor. 

Basser  Computing  Dept.  Tech.  Report  II,  .Sydney,  Aus- 
tralia, March,  1060. 

9.  Griswold,  R.  E.,  and  Polonsky,  I.  P.  String  pattern  match- 

ing in  the  programming  language  SXOBOL.  Bell  Labora- 
tories, July  1,  1963. 

10.  Wilkes,  M.  V.  An  experiment  with  a self-compiling  com- 

piler for  a simple  list  processing  language.  In  Richard 
Goodman  (Ed.),  Annual  Review  in  Automatic  Programming, 
1 'of.  i,  Pergnmon  Press,  Xetv  York,  1964,  p.  1. 

11.  Orgass,  R.  J.,  Schorr,  H.,  Waite,  W.  M.,  and  Wilkes, 

M.  V.  WISP— a self-compiling  list  processing  language. 
Basser  Computing  Dept.  Tech.  Report  36,  Sydney,  Aus- 
tralia, Oct.  1965.  ( 

12.  Warshall,  S.,  and  Shapiro,  R.  M.  A general-purpose 

table-driven  compiler.  Proc.  AKIPS  1961  Spring  Joint  Com- 
put. Conf.,  Yol.  25,  p.  59. 

13.  Leavenworth,  B.  M.  Syntax  macros  and  extended  transla- 

tion. Comm.  ACM  9 (Xov.  1966),  790. 


Proposed  USA  Standard 

COBOL 

is  now  available 

• This  important  Proposed  I'SA  Standard  COBOL  is  contained  in  an  issue  of  the  ACM  S1CPLAX  Notices  (Volume  2, 

i Numlter  4.  April  1907i.  which  was  distributed  in  June  to  the  regular  ACM  SICPLAX  mailing  list.  It  has  also  been 

sent  to  the  COBOL  Information  Bulletin  mailing  list. 

• To  interested  persons  not  on  either  of  the  mailing  lists  for  the  above  publications,  this  Proposed  COBOL  Standard 
is  available  at  83.00  |>cr  copy.  Orders  must  be  prepaid  and  should  be  addressed:  COBOL,  Association  for  Computing 
Machinery.  211  least  43rd  Street,  New  York,  New  York  10017.  A s|xteial  price  of  S2.50  per  copy  is  being  granted  by 
ACM  lor  bulk  orders  of  50  or  more. 

• I'SA  Standards  Committee  X3  has  authorized  publication  of  this  document,  which  contains  538  pages,  to  elicit 
comment  and  criticism  from  the  data  processing  community  prior  to  voting  on  its  acceptance  as  a I'SA  Standard. 
Comments  should  lx;  addressed  to:  N3  Secretary,  Business  Equipment  Manufacturers  Association,  235  East  42nd 
Street.  Now  York,  New  York  10017. 


I 


110 


Communications  of  the  ACM 


Volume  10  / Number  7 / July,  1967 


REFERENCES 

1.  Gray,  J.  C.  Compound  data  structure  for  computer  aided 
design;  a survey,  l’roc.  ACM  22nd.  Nat.  Conf.  19G7,  Thomp- 
son Book  Co.,  Washington,  D.  C.,  pp.  355-305. 

2 Hansen,  W.  J.  The  impact  of  storage  management  on  the 
implementation  of  plex  processing  languages.  Tech.  Rep, 
No.  113,  Computer  Science  Dcp.,  Stanford  U.,  Stanford, 
Calif.,  1909. 

3.  Knuth,  D.  E.  The  Arl  of  Computer  Programming,  Vol.  1. 

Addison-Wesley,  Menlo  Park,  Calif.,  1968. 

4.  Lang,  C.  A.,  and  Gray,  J.  C.  ASP — A ring  implemented 

associative  structure  package.  Comm.  ACM  11,  8 (Aug.  1968), 
550-555. 

5.  McCarthy,  J.,  et  al.  LISP  1.5  Programmer ’*  Manual. 

MIT  Press,  Cambridge,  Mass.,  1962. 

G.  Minsky,  M.  L.  A LISP  garbage  collector  using  serial  sec- 
ondary storage.  MIT  Artificial  Intelligence  Memo.  No.  58, 
MIT,  Cambridge,  Mass.,  Oct.  1963. 


7.  Ross,  D.  T.  A generalized  technique  for  symbol  manipula- 

tion and  numerical  calculation.  Comm.  ACM  i,  3 (Mar. 
1901),  147-150. 

8.  . The  AED  free  storage  package.  Comm.  ACM  10,  8 

(Aug.  1967),  481-492. 

9.  Reynolds,  J.  C.  Cogent  programming  manual.  Argonne 

Nat.  Lab.  Rep.  No.  ANL-7022,  Argonne,  Illinois,  Mar. 
1965. 

10.  Schorr,  H.,  and  Waite,  W.  M.  An  efficient  machi.ie-inde- 

pendent  procedure  for  garbage  collection  in  various  list 
structures.  Comm.  ACM  10,  8 (Aug.  1907),  501-506. 

11.  Stygar,  P.  LISP  2 garbage  collector  specifications.  TM- 

3417/500/00,  System  Development  Corp.,  Santa  Monica, 
Calif.,  Apr.  1967. 

12.  Wiseman,  N.  E.  A simple  list  processing  package  for  the 

PDP-7.  In  DECUS  Second  European  Seminar,  Aachen, 
Germany,  Oct.  1966,  pp.  37-42. 


A Base  for  a Mobile 
Programming  System 

Richard  J.  Orgass 

IBM  Thomas  J.  Watson  Research  Center 

Yorktown  Heights,  Xew  York 

AND 

William  M.  Waite 

Uni.ersily  of  Colorado,  Boulder,  Colorado 

An  algorithm  for  o macro  processor  which  hos  been  used  as  the 
base  of  an  implementation,  by  bootstrapping,  of  processors 
for  programming  languages  is  described.  This  algorithm  can 
be  easily  implemented  on  contemporary  computing  machines. 
Experience  with  programming  languages  whose  implementa- 
tion is  based  on  this  algorithm  indicates  that  such  a language 
can  be  transferred  to  a new  machine  in  less  than  one  man-week 
without  using  the  oid  machine. 
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1.  Introduction 

The  development  of  many  special  purpose  programming 
languages  has  increased  the  overhead  associated  with 
changing  computing  machines  and  with  transferring  a 
programming  language  from  one  computer  center  to 
another.  A number  of  writers  have  proposed  that  these 
la  iguages  should  be  implemented  by  bootstrapping.  (Since 
this  work  is  wed  known,  it  is  not  summarized  in  this  in- 
troduction.) 

The  description  is  given  of  a bootstrapping  procedure 
which  does  not  require  a running  processor  on  another 
machine  for  its  implementation.  A compiler  is  described 
which  can  be  trivially  implemented  “by  hand”  on  con- 
temporary computing  machines.  This  simple  compiler  is 
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then  used  to  translate  a more  elaborate  one,  and  so  forth, 
until  the  desired  level  of  complexity  is  reached. 

This  paper  is  a complete  description  of  the  first  stage  of 
such  a bootstrapping  procedure.  It  is  organized  as  follows: 
in  Section  2,  the  processing  performed  by  the  simple  com- 
piler (SIMC.MP);  in  Section  3,  some  examples  of  its  use; 
in  Section  4,  the  environment  which  must  be  coded  for  a 
particular  computing  machine;  and  in  Section  5,  the 
SIMCMP  algorithm. 

2.  Specifications  for  SIMC.MP 

The  algorithm  described  in  this  paper  was  constructed 
to  provide  a compiler  of  minimum  length  and  complexity 
which  is  adequate  to  serve  as  the  base  for  the  implemen- 
tation, by  bootstrapping,  of  programming  systems. 
SIMCMP  is  essentially  a very  simple  macro  processor. 
Source  language  statements  are  defined  in  terms  of  their 
object  code  translations.  These  definitions  are  stored  in  a 
table.  A source  program  is  translated  one  line  at  a time. 
The  input  line  is  compared  with  all  of  the  entries  in  the 
table.  When  a match  occurs,  the  object  code  translation 
of  the  input  line,  with  appropriate  parameter  substitu- 
tions, is  punched.  SIMCMP  can  be  used  to  translate  any 
source  language  which  can  be  defined  by  means  of  simple 
substitution  macros  with  single  character  paramo  ers. 

Several  terms  as  they  are  used  in  this  paper  are  illu- 
strated here.  In  a conventional  macro  processor,  a macro 
definition  is  of  the  form: 

MACRO  NAME  (Pi , • • • , P„) 

Code  body 
END 

The  strings  ‘MACRO’  and  ‘END’  serve  to  delimit  the 
macro  definition.  ‘NAME’  stands  for  the  name  of  the 
macro,  and  ‘Pf,  • • • , ‘Pn’  stands  for  the  formal  parameters 
of  the  macro.  This  macro  is  called  by  a line  of  the  form 
‘NAME  (.4i , • • • , .4 „) ’ where  m is  less  than  or  equal  to  n. 
When  this  eall  is  encountered  in  the  program  text,  the 
code  body  of  the  macro  NAME  is  evaluated  by  sub- 
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stituting  the  values  of  ‘/li’,  •••  , ‘.-l*’  for  occurrences  of 
'iY,  • • • , ‘IV.  If  in  i»  less  than  n,  then  values  for  actual 
parameters  ‘AmrX’,  , ‘.i„’  are  generated  by  the  macro 
processor  in  some  regular  way. 

SIMCMP  differs  from  a conventional  macro  processor 
in  that  the  line  which  introduces  a macro  definition  may 
he  an  arbitrary  string  of  characters,  with  parameters  in- 
dicated by  a special  symbol  called  a parameter  Jlaij.  This 
line  is  referred  to  as  the  template.  The  effect  of  using  a 
template  is  to  allow  the  name  part  of  a traditional  macro 
to  be  replaced  by  a "distributed  name”  which  consists  of 
all  the  characters  in  the  line  except  the  parameter  flags. 
Except  for  the  parameter  flags,  each  character  of  the 
template  must  match  the  corresponding  character  of  the 
input  line  exactly.  A parameter  flag,  however,  may  match 
any  single  character.  That  is,  the  template  line  may  be 
thought  of  as  a mask  consisting  of  literal  characters  inter- 
spersed with  "holes”  which  correspond  to  arbitrary  char- 
acters in  the  input  string  being  matched.  The  character 
which  is  matched  by  a particular  parameter  flag  becomes 
the  value  of  the  formal  parameter  which  is  denoted  by  this 
parameter  flag. 

The  code  body  of  a SIMCMP  macro  consists  of  lines 
in  the  target  language  with  references  to  parameters  sub- 
stituted for  some  elements  of  the  lines.  That  is,  each  line 
consists  of  a series  of  strings  of  characters  and  references 
to  parameters.  A reference  to  a parameter  is  signaled  by 
a special  character  called  a machine  language  (MCT) 
parameter  flag.  This  flag  is  followed  by  two  digits,  the  first 
of  which  specifies  the  number  of  the  formal  parameter  in 
the  template,  counting  fro  nr  the  left.  The  second  digit 
of  the  parameter  call  defines  the  type  of  conversion  to  be 
used  in  the  particular  substitution  instance  of  the  formal 
parameter.  A maximum  of  nine  formal  parameters,  num- 
bered 1 to  9,  may  be  specified  in  a single  template.  The 
two  conversion  types  which  are  available  are  described 
below. 

The  SIMCMP  translator  has  two  main  phases:  macro 
definition  and  macro  expansion.  During  the  macro  defi- 
nition phase,  user-defined  macros  are  read  and  stored  in 
an  array.  The  first  input  line  for  SIMCMP  is  called  the 
flag  line  and  contains  five  control  characters.  The  first  is 
the  source  language  end-of-line  flag,  a character  which 
marks  the  end  of  characters  to  be  translated  in  an  input 
line.  The  second  character  is  the  source  language  parameter 
flag  which  is  used  in  templates  to  indicate  the  position  of 
formal  parameters.  The  third  and  fourth  characters  of 
the  flag  line,  respectively,  are  the  MCT  end-of-line  and 
the  MCT  parameter  flags.  The  first  marks  the  end  of  use- 
ful information  in  a code  body  line;  the  second  indicates 
that  a converted  actual  parameter  should  be  inserted  at 
thi>  point  in  the  machine  code  output.  The  fifth  char- 
acter on  the  flag  line  must  be  the  character  ‘O’.  Following 
the  flag  line  is  a scries  of  macro  definitions.  Each  macro 
definition  is  terminated  by  a line  whose  first  character  is 
the  MCT  end-of-line  flag.  After  this  line,  a new  template 
must  appear.  If  a particular  macro  is  the  last  one  to  be 
defined,  then  the  first  two  characters  of  its  terminating 
line  arc  machine  code  end-of-linc  flags. 


After  all  of  the  macro  definitions  have  been  read, 
SIMCMP  enters  the  expansion  phase.  A single  scurce 
statement  is  read  into  the  array.  Reading  is  terminated 
when  a source  end-of-line  flag  occurs  in  the  input  stream. 
This  statement  is  translated  by  successively  matching  it 
against  each  of  the  defined  template-.  Before  this  com- 
parison is  done,  a check  is  made  to  ensure  that  the  source 
line  is  not  void  (a  void  line  terminates  the  program  to  be 
translated).  During  the  matching  process,  a character 
which  is  matched  against  a source  language  parameter 
flag  in  the  template  is  piaced  in  the  corresponding  parame- 
ter storage  word.  If  all  the  characters  in  the  input  line 
are  successfully  matched,  the  input  line  is  accepted  as  a 
call  on  the  macro  whose  template  is  currently  being 
scanned.  If  SIMCMP  fails  to  find  a match  for  some 
character  of  the  input  line,  an  attempt  is  made  to  match 
this  input  line  to  the  next  template.  If  all  templates  have 
been  compared  with  an  input  line  and  there  is  no  match, 
then  the  input  line  is  assumed  to  be  in  the  target  language 
and  it  is  punched  out  without  translation.  After  processing 
an  input  line,  the  next  input  line  is  processed,  ami  so 
forth,  until  a viod  line  is  encountered. 

Since  the  templates  arc  scanned  in  order,  an  input  line 
which  matches  several  templates  will  be  treated  as  an 
instance  of  the  first  template  encountered.  Therefore,  it 
is  the  responsibility  of  the  user  to  ensure  that  the  order- 
ing of  the  macro  definitions  will  not  produce  strange 
results. 

When  an  input  line  has  been  matched  to  a particular 
template,  the  lines  of  its  associated  code  body  arc  punched 
out.  Characters  other  than  the  formal  parameters  arc 
punched  exactly  as  they  appear  in  the  code  body  and 
call  on  formal  parameters  are  replaced  by  the  values 
specified  by  the  conversion  digit  and  the  actual  parameter 
value.  Two  conversion  types  are  available:  type  0 and 
type  1.  Type  0 conversion  is  a direct  copy  of  the  actual 
parameter  into  the  output  string.  For  each  computing 
machine,  the  user  of  SIMCMP  must  define  a one-to-one 
mapping,  M,  from  the  character  set  of  his  computing 
machine  onto  a set  of  positive  integers.  The  only  restric- 
tion on  M is  that  the  characters  0 to  9 must  map  onto 
successive  integers.  Type  1 conversion  produces  as  output 
the  numeral  which  denotes  the  image  of  the  actual  pa- 
rameter under  the  mapping  M. 

For  some  target  languages,  it  is  necessary  to  SIMCMP 
to  be  able  to  generate  arbitrary,  unique  symbols.  This 
capability  is  provided  by  means  of  parameter  zero.  Up 
to  ten  unique  symbols  may  be  generated  during  the  ex- 
pansion of  a single  macro  by  referring  to  parameter  zero 
with  conversion  type  0 to  9.  The  conversion  type,  in  this 
case,  indicates  which  of  the  created  symbols  is  being  re- 
ferred to  (for  example,  ‘00’  refers  to  the  first  created  sym- 
bol, ‘01’  refers  to  the  second  created  symbol,  etc.).  These 
symbols  are  three-digit  decimal  numerals;  the  first  one 
denotes  the  integer  100.  These  numerals  are  supplied  by  a 
“location  counter”  which  is  maintained  by  SI  MCMP.  This 
location  counter  is  initially  set  to  the  value  100;  after 
processing  a macro  w hich  contains  references  to  parameter 
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0,  its  value  is  incremented  by  one  more  than  the  highest 
conversion  digit  used. 

The  structure  of  the  translation  performed  by  SIMCMP 
imposes  restrictions  on  both  the  source  language  and 
the  target  language.  Restrictions  on  the  source  language 
syntax  are  not  important  because  the  only  purpose  of 
SIMCMP  is  to  compile  the  next  compiler  in  the  bootstrap 
sequence.  Restrictions  on  the  target  language  are  more 
serious;  so  we  have  attempted  to  generalize  the  program 
without  compromising  our  design  objectives. 

3.  Examples 

The  compiler  for  the  list  processing  language  WISP 
(1]  is  written  in  a subset  of  itself  which  can  be  compiled 
by  SIMCMP.  SIMCMP  has  been  used  to  implement  the 
WISP  language  for  several  computing  machines.  The 
programming  effort  required  to  implement  WISP  in 
this  manner  is  about  one  man-week.  The  macro  processor 
LIMP  [2]  is  written  in  the  programming  language  WISP 
and,  consequently,  is  available  once  WISP  has  been 
implemented. 

VTSP  may  be  described  approximately  by  saying  that 
it  is  a simple  version  of  the  '“program  feature”  of  LISP 
|3].  The  examples  given  here  are  taken  from  the  subset  of 
WISP  which  is  compiled  by  SIMCMP.  In  order  to  pro- 
vide examples  which  do  not  refer  to  a particular  comput- 
ing machine,  the  Fortran  II  programming  language  is 
used  as  the  target  language.  In  actual  practice,  the  target 
language  would  be  the  assembly  code  of  a particular 
macltinc. 

Figure  1 contains  examples  of  two  SIMCMP  macros 
and  illustrations  of  the  output  produced  by  SIMCMP  for 
particular  source  language  strings  as  inputs.  In  this  figure, 
the  source  language  and  MCT  end-of-line  flags  are 
The  source  language  parameter  flag  is  and  the  MCT 
parameter  is 

An  example  of  the  use  of  parameter  0 is  given  in  Figure 
2.  The  flags  in  this  figure  arc  the  same  as  those  in  Figure 

1.  Since  the  target  language  is  Fortran  II,  arbitrary 
labels  mast  be  generated  because  three  labels  must  be 
specified  for  the  IF  statement.  When  the  condition  is  not 
satisfied,  control  is  to  pa«s  to  the  next  statement,  which 
must  be  assigned  a label.  SIMCMP  produces  this  label 
automatically  by  means  of  parameter  0. 

4.  The  Environment  for  the  Simple  Compiler 

The  environment  for  SIMCMP  is  defined  to  be  all 
programs  which  are  required  to  use  SIMCMP  on  a par- 
ticular computing  machine.  That  is,  the  environment 
includes  input  and  output  programs,  the  assembler  for 
this  computing  machine,  and  a driver  program.  (The 
SIMCMP  algorithm  i-  given  as  a procedure.)  The  input 
program  is  used  to  reati  from  a source  created  by  the  user. 
This  source  is  to  be  organized  into  lines.  For  remote 
terminal  or  paper  tape  oriented  machines,  a line  is  de- 
limited by  carriage  returns.  For  card  oriented  machines, 
each  card  is  a line  and  is  considered  to  have  a carriage 
return  follow  mg  the  SOth  character. 


The  output  program  is  ased  to  write  text  which  is  to  be 
processed  by  the  assembler;  the  output  text  is  also  or- 
ganized into  iincs. 

The  input  program  (I READ)  is  an  integer  procedure 
with  one  parameter.  The  value  returned  by  this  pro- 
cedure depends  on  the  value  of  the  parameter  and  the 
next  character  in  the  source.  The  parameter  of  IR'SAD 
may  have  the  value  0 or  1.  If  IREAD  is  called  w.th  a 
parameter  whose  value  is  1,  then  the  value  returned  by 


. = CAR... 

I = CDR(’21). 

CDR('ll)  = CAR(I). 

X 

(a)  Example  of  SIMCMP  macro  definition. 

A = CAR  B. 

(b)  A string  which  matches  the  template  of  (a). 

1 = CDR(3S) 

CDR(3G)  = CAR(I) 

(c)  A possible  output  from  macro  (a)  when  string  (b)  is  the  input 

* =3  •**  •. 

I = CDR('41). 

J = CDR('Sl). 

’10’20’30(I)  = 'o0'G0’70(J). 

.X 

(d)  Another  example  of  a SIMCMP  macro  definition 

CARA  = CDR  B. 

(e)  A string  which  matches  the  template  of  (d). 

I ■=  CDR  (36) 

J = CDR(3S) 

CAR(I)  = CDR(J) 

(f)  Output  produced  by  SIMCMP  when  string  (d)  is  the  input. 

Fig.  1.  Examples  of  SIMCMP  macros 

TO  ..  IF  CAR  .]=  CDR  .. 

I = CDR  ('31). 

J - CDR('-U). 

(IF  (CARR)  - CDR(J))'00,  '10'20,  '00. 

'00  CONTINUE. 

X 

(a)  A SIMCMP  macro  definition  which  uses  parameter  zero. 

TO  13  IF  CAR  A - CDR  B. 

(b)  A string  which  matches  the  template  of  (a). 

I = CDR(3G) 

J ■=  CDR  (38) 

IF  (CARR)  - CDR(J))100,  13,  100 

100  CONTINUE 

(c)  Output  produced  by  SIMCMP  if  string  (b)  is  the  first  input 
string  which  matches  a template  whose  definition  uses  param- 
eter zero. 

TO  14  IF  CAR  B » CDR  A. 

(d)  A string  which  matches  the  template  of  (a). 

I = CDR  (38) 

J = CDR(3G) 

IF  (CARR)  - CDR(J))101, 14,101 

101  CONTINUE 

(c)  Output  produced  by  SIMCMP  if  string  (d)  is  the  second  input 
string  which  matches  a template  whose  definition  uses  param- 
eter zero. 

Fig.  2.  Example  of  the  use  of  parameter  zero 
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the  procedure  is  the  integer  which  corresponds  to  the  next 
character  in  the  source  under  the  mapping  M.  Note  that 
it  is  assumed  that  the  source  is  organized  so  that  the  first 
character  of  a line  immediately  follows  the  carriage  re- 
turn of  the  line  which  precedes  it.  The  carriage  return 
itself  corresponds  to  the  integer  — 1. 

If  1READ  is  called  with  a parameter  whose  value  is  0, 
then  the  value  returned  by  the. procedure  is  undefined. 
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SUBROUTINE  SlMCMPlLlST.XMAX) 

01 MENS I Oh  LlSTI UMAX  * . _ „ 

READ  CONTROL  CHARACTERS.  IN  T«t  ORDER  - 

SOURCE  EOL.  SOURCE- PARAK.  MCT 


00  1 1-1.5 

L l ST  I I I • I REAOC 1 1 
L 1ST  16 1 • 100 
X-17 

HEAD  MACRO  DEFINITIONS 

1 ■ 1READI0 ) 
t»K*l 

USTIL»«-1 


I -L 

IF  II  #6E • XMAXI 


STOP 


I ■ I ♦! 

L 1 ST  I I I • 1 RE AO 1 1 ) 

IF  IlISTCII  .NE*  LlSTllll  00  TO  3 

j>lRfAO<OI 

J-IM 


I • I ♦ 1 

IF  (I  .GE.  XMAXI  STOP 
L I ST  f I 1 ■ IREAOl 1 ) 

IF  I L 1 ST  I 1 I .NE.  L1ST<*|»  GO  TO  12 
LlS*! 1 l-Lt STISl-lREAOIll-7 
I • » 

LlSTI  I I-IREADID-LISTIS) 

IF  (LIST  I 1-1)  .NE.  (-7))  GO  TO  7 

IF  I L 1 ST  I l I .LT.  LlSTI!))  L I ST (L ) -L I Si (I > 

GO  TO  7 

IF  < L.  1 ST  II)  .NE.  LIST  13) ) GO  TO  7 
LlSTI  I)  — 1 

|F  II  .SL\  Jl  GO  TO  6 
L 1ST  IX) ■ I 


X-I 

IF  1 1 RE AO  I 1 ) .NE.  L I ST  I 3 ) ) GO  TO  2 
READ  A SOURCE  STATEMENT 

20  I • I READ  1 0 1 

21  DO  22  l-X.XMAX 
LlSTI  I i-IREADll) 

J F I L 1 ST  I 1 ) .EO.  LlSTllll  GO  TO  30 
IF  I l 1 ST  I 1 ) .EO.  I -1 ) ) GO  TO  52 

22  CONTINUE 
STOP 

TRANScATc  ONE  STATEMENT 
30  IF  <1  .EO.  XI  RETURN 
M»I  7 


N«P*1 

DO  3*  JaX.I 


N«N*1 

IF  ILlSTINI  .EO.  L 1 ST  1 2 I I GO  TO  33 
IF  IliSTiN)  .£0.  LlSTIJI)  GO  TO  3<* 
32  M»L ISTIMI 

IF  i»*-X  » 31.50.53 
y\  |F  il  .Ew.  J)  GO  10-32 
w 1 ST  I L I “L 1 ST  I U) 

L»L-l 

3L  CONTINUE 
GO  TO  41 

PUNCH  MACHINE  COOE  TRANSLATION 


EOL.  MCT  PARAM.  ZtRO. 


AO  CALL  IPNCHIlISTIN) I 
A 1 N «N* 1 

IF  IlISTIM)  ,cq.  m GO  TO  a7 
IF  ILlSTINI  .GE.  1-131  GO  TO  AO 
L—L 1ST  IN) 

N-N-  1 

IF  il  .EO.  Tl  GO  TO  A2 
IF  ILlSTINI  .NE.  01  GO  TO  43 
CALL  IPNCHlLlSTIL) ) 

GO  TO  A 1 


GO  TO  20 

c convert  m parameter  to  an  integer 
A?  UST|7|.IISTINI*L1ST(6I 
A)  :*listili 

00  44  j-X.XMAX 
L • I / 10 

L 1ST  I Jl«  I-ILMO) 

IF  It  .EO.  01  GO  TO  4> 


A4 . | -L 
STOP 

4 S CALL  IPNCmilISTI Jl-LISTISI) 

J-J-l 

IF  Ij  .GC.  X)  GO  TO  AS 
GO  TO  41 

C fjNCM  OUT  an  UNREC0GNI2E0  LINE  AFTER  GETTING  IT  All 
SC  J-l-l 

00  SI  IO.XMA( 

L 1ST! I I • IREAOl 1) 

(L)STill  .£0.  1-1  I I GO  TO  32 
S 1 continue 
STOP 

s:  h o si  j • a » i 

Cali  ipnchilisti  ji  i 
GO  ro  21 
f NO 


IN 


Fio.  3.  The  SIMCMP  algorithm 


However,  this  call  causes  the  input  stream  to  be  moved 
forward  until  a carriage  return  character  has  been  p issed. 
That  is,  after  such  a call,  the  next  call  to  IltEAD  with  a 
parameter  whose  value  is  1,  returns  as  its  value  the  in- 
teger which  corresponds  to  the  first  character  of  the  next 
input  line.  Successive  calls  I READ  (0)  may  be  used  to 
skip  input  lines. 

The  output  program  (IPNCH)  is  a procedure  with  one 
argument  which  is  used  to  convert  integers  to  the  char- 
acters to  which  they  correspond.  The  statement  CALL 
IPNCH(I)  causes  the  character  which  corresponds  to  I 
to  be  placed  in  the  output  character  stream.  Since  the 
integer  —1  corresponds  to  the  carriage  return,  CALL 
IPNCH(— 1)  terminates  the  current  output  line.  That  is, 
for  a card  oriented  machine  it  causes  the  termination  of 
the  current  output  card;  for  a remote  terminal  or  paper 
tape  oriented  machine,  it  causes  the  carriage  return 
character  to  be  placed  in  the  output  stream. 

By  contemporary  standards,  the  assembler  required  for 
the  SIMCMP  environment  is  quite  simple.  This  assembler 
must  be  capable  of  assigning  values  to  symbolic  addresses 
which  are  strings  built  up  out  of  numerals  or  numerals 
and  other  characters.  The  symbols  generated  by  SIMCMP 
are  always  strings  of  numerals.  However,  the  translation 
rules  may  be  written  so  that  a string  of  numerals  is  pre- 
ceded or  followed  by  another  string  of  characters.  This 
assembler  must  have  a facility  for  reserving  storage. 

The  driver  program  defines  the  storage  used  by  the 
procedure  SIMCMP  and  calls  this  procedure.  It  may  also 
be  used  to  take  care  of  bookkeeping  functions.  During 
translation,  SIMCMP  requires  a single  integer  array  and 
six  temporary  storage  locations.  The  array  must  be  large 
enough  to  contain  all  of  the  translation  rules  (stored  one 
character  per  element)  and  a single  input  line.  In  addition, 
fifteen  elements  of  the  array  plus  two  elements  per  trans- 
lation rule  are  used  for  control  information. 

5.  The  SIMCMP  Algorithm 

The  SIMCMP  algorithm  is  shown  in  Figure  3.  This 
algorithm  is  stated  as  a Fortran  IV  subroutine.  It  has 
been  used  in  this  form  with  an  IBM  704-1,  an  IBM  300/50, 
and  a CDC  0400. 

The  two  parameters  are  the  array  described  in  Section 
4 (LIST)  and  the  number  of  elements  in  this  array 
(KMAX).  The  comments  in  the  program  explain  its 
operation,  although  this  information  is  not  required  for 
the  use  of  the  program. 
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Syntax  Macros  and  Extended 
Translation 

B.  M.  I.KAV  EX  WORTH 

/ nit,  national  Business  Machines  Corporation  * 

York! uun  Heights.  Seu • York 

A tronslolion  approach  is  described  which  allows  one  to 
extend  the  syntax  and  semantics  of  a given  high-level  base 
language  by  (he  use  of  a new  formalism  called  a syntax- 
macro.  Syntax-macros  define  string  transformations  based 
on  syntactic  elements  of  the  base  language.  Two  types  of 
macros  are  discussed,  and  examples  are  given  of  their  use. 
The  conditional  generation  of  macros  based  on  options  and 
alternatives  recognized  by  the  scan  are  also  described. 

I nt rod  notion 

The  procedure  concept  in  programming  has  been  de- 
veloped into  an  elegant  and  powerful  tool  [1-3J.  However, 
the  jxitential  extension  of  current,  procedural  languages 
into  special  purpose  areas  seems  to  require  a more  flexible 
facility  than  offered  by  the  procedure.  On  the  other  hand, 
the  conventional  macro,  also  considerably  developed 
[4,  5],  has  still  been  based  essentially  on  symbolic  as- 
sembly code.  The  purpose  of  this  paper  is  to  suggest  a 
generalization  of  the  macro  concept  to  high-level  languages, 
which  allows  the  programmer  10  extend  the  syntax  and 
semantics  of  a given  base  language  by  new  statements 
or  expressions.  The  constituents  of  the  new  type  of  macro, 
called  a syntax-macro,  are  syntactic  elements,  or  con- 
structs of  the  base  language,  rather  than  fragments  of 
machine  instructions  as  is  the  case  with  conventional 
macros.  The  objective  of  this  work  is  to  develop  powerful 
inodes  of  expression  and  reference  by  using  flexible  sj’ntax 
and  multiple  levels  of  definition. 

Syntax  Macros 

A syntax-macro  has  two  parts: 

) a macro  slntclurc  which  describes  the  syntax  of 
the  source  text  to  Ik-  recognized; 

(2>  a macro  <h finitioh  which  describes  the  semantics 
of  tin  corresponding  macro  structure. 

• ,\dv.»ncro  systems  Development  Division 
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The  macro  structure  is  a string  of  metavariables  and 
basic  symbols.  The  first  symbol  of  the  string  must  be  a 
unique  basic  symbol  called  the  macro  delimiter.  The 
metavariables  are  the  parameters  of  the  macro  and  arc 
drawn  front  the  metavariables  (i.e.,  constituents  of  the 
syntax)  available  in  the  base  language.  For  the  present 
discussion,  two  types  of  macros  are  assumed  to  be  avail- 
able: statement  macros  and  function  macros. 

The  macro  definition  is  also  a string  of  metavariables 
and  basic  symbols.  Each  metavariable  in  the  definition 
must  appear  in  the  structure.  Metavariables  in  the  struc- 
ture arc  ordered  from  left  to  right,  and  each  is  referenced 
in  the  definition  by  inserting  the  ordinal  number  of  the 
variable  in  question,  preceded  by  the  meta>ymbol,  ‘S'.  A 
syntax-macro  may  be  thought  of  as  a string  function 
whose  domain  is  the  macro  structure  and  whose  range  is 
the  macro  definition.  Both  structure  and  definition  must 
have  the  same  syntactic  type.  A syntax-macro  is  de- 
clared as  follows: 

macro  U define  V cndmacro 

where  macro  stands  for  either  smacro  (statement  macro) 
or  fnincro  (function  macro),  U stands  for  the  macro 
structure,  and  F for  the  definition. 

To  illustrate  a syntax-macro,  it  is  necessary  first  to 
specify  a base  language.  The  following  grammar  defines  a 
base  language  Lb  : 

program  ::=■  block 

block  begin  [local  identifier;]  ■ ■ • state-list  end 
state-list  statement  [;  statement]  ••• 

statement  variable  *—  express  | go  to  identifier  ] if  express 
then  statement  ( block  | result  express  | label  statement  | 
s-macro-call 

express  ::=»  a-term  [rclatop  a-term) 
a-ternt  6-term  [(+  | — | 6-tcrm]  ••• 

6-tcrm  primary  ((*  1 /)  primary)  ••• 

primary  ::*■  variable  | constant  |(exprcss}|  block  | /-macro  call 

variable  ::=■  identifier  ((expressf,  express)  • • • )) 
relatop  < l S | - 1 ^ I > I § 

The  syntax  notation  employed  here  follows  that  in  the 
PL/I  report  [3],  namely: 

| ) braces  denote  grouping, 

[ ) square  brackets  denote  optional  occurrence, 
i vortical  stroke  separates  alternatives, 

three  dots  denote  the  occurrence  of  the  immediately  pre- 
ceding syntactical  unit  one  or  more  times  in  succession. 

Metavariables  arc  lower-case  words,  with  the  exception 
of  tlic  following:  “identifier,”  “constant”  and  “label 
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(wliicli  lias  the  form  ‘•identifier:’’)  are  scanned  by  the 
translator  as  basic  symbols.  Other  basic  symbols  are 
special  characters  ami  Keywords  (denoted  by  boldface 
type)- 

The  semantics  of  Lu  are  not  defined  rigorously  here, 
l,t  t they  could  be  specified  by  a real  or  simulated  machine. 
X >tc  that  a block  may  act  as  either  a statement  or  a 
primary.  The  use  of  a block  as  a primary  allows  the  desig- 
nated result  of  a series  of  statements  (status  changes) 
to  be  embedded  as  a value  in  the  context  of  a larger  ex- 
pression. This  end  value  is  defined  by  using  the  result 
statement  before  exit  from  the  block.  A block  also  serves 
to  qualify  local  identifiers  and  labels,  and  to  protect  them 
from  similar  names  in  the  external  environment.  A macro- 
call is  a macro  structure  with  the  metavariables  replaced 
with  literal  strings  (actual  parameters).  When  the  macro- 
call is  scanned,  each  literal  string  must  agree  with  the 
syntactic  type  of  its  corresponding  metavariable.  After 
the  proper  substitutions  have  been  made  for  the  meta- 
variables in  the  definition,  the  resulting  string  must  be  a 
syntactically  correct  string  in  the  base  language.  A simple 
for  statement  may  now  be  dofineu  in  terms  of  LB  by  the 
following  statement  macro. 

smucro  for  variable  •—  express  to  express  do  statement 
define  begin  SI  *—  S2; 

LI  : if  $1  g S3  tlxen 

begin  $4;  ' $1  «—  $1  + 1 ; 

go  to  LI 
end 
end 

end  macro 

Notice  that  both  the  structure  and  definition  of  the 
above  macro  have  t he  same  syntactic  type,  i.e.,  statement. 
This  is  essential  for  correct  analysis.  The  macro  delimiter 
in  this  example  is  “for”;  once  a macro  delimiter  appears 
in  a new  macro  declaration,  it  becomes  a ‘‘reserved  word” 
and  may  only  be  used  in  the  call  of  this  macro. 

In  the  ease  of  the  macro  call, 

for  k — 1 to  n+1  do  j j+m[k] 

the  correspondence  between  metavariables  and  literal 
strings  is  shown  below: 

metavariable  syntactic  type  literal  string 

$1  variable  k 

$2  express  1 

S3  express  n+1 

$4  statement  j *—  j+m[fc] 

The  above  macro  call  would  expand  into  the  following 
string: 

begin  k *—  1 ; 

I A : if  k g n + 1 then 

tK*gin  j ♦—  j+mttrl; 

k *—  k-r  1 ; 

go  to  L\ 
end 

end 

The  second  type  of  macro  to  be  considered  is  the'  func- 
tion macro.  Consider  the  following  declaration,  which 


contains  a call  to  the  for  macro  in  its  definition: 

fmacro  sum  express  with  variable  «—  express  to  express 
define  begin  local  t; 

t — 0;  for  $2  <-  $3  to  S4  do 
<♦—!  + $ 1;  result  t 

end 

endmacro 

The  purpose  of  the  function  macro  is  to  produce  a value 
which  may  be  embedded  in  an  expression.  The  syntactic 
type  of  an  /-macro-call  is  a primary,  which  is  consistent 
with  the  usage  of  ordinary  functions  in  programming 
languages. 

To  illustrate  these  ideas,  consider  the  statement, 
c ♦—  a • sum  6(A)  with  A* «—  1 to  10 

which  contains  a call  to  the  /-macro  sum.  Expansion  pro- 
duces 

c *—  a * begin  local  !;  t ♦—  0; 
for  A:  ♦—  1 to  10  do 

<*—!+■  6(A);  result  l 
end 

and  expansion  of  the  for  macro  yields 

e *—  a • begin  local  t;  I •—  0; 
begin  k <—  1 ; 

LI:  if  k S 10  then 
begin  t *—  l + 6 (A-)  I 
k *-  k + 1;  go  to  /.I 
end 

end;  result  t 
end 

Nested  calls  such  as  the  following  can  also  be  made: 
sum  sum  b(J,  A)  with  A;  <—  1 to  20  with  j ♦—  1 to  10 

The  effect  of  macro  recognition  and  expansion  is  the 
replacement  of  one  string  by  another.  If  the  new  string 
contains  no  macro  delimiters,  i.e.,  it  is  a string  in  the  base 
language,  it  can  then  be  scanned  and  transformed  accord- 
ing to  the  semantics  of  the  base  language;  otherwise  the 
process  is  repeated.  Because  the  scope  of  literal  strings  is 
determined  by  syntactic  analysis,  actual  parameters  need 
not  be  delimited  by  special  symbols  like  commas  in  an 
argument  list.  Further,  certain  symbols  used  as  separators 
may  also  be  contained  in  actual  parameters.  For  example, 
in  the  macro  structure: 

signal  express  (state-list) 

any  literal  string  corresponding  to  the  metavariable 
“express”  may  contain  nested  parentheses. 

Parsing  Method 

In  principle,  any  method  of  syntactic  analysis  that 
produces  a structural  description  [6]  of  source  text  can  be 
used  for  macro  recognition.  Whenever  a programmer  is 
given  the  right  to  add  new  syntax  rules  to  a base  language, 
the  parsing  method  should  be  specified  in  order  to  remove 
ambiguity.  The  method  assumed  in  these  illustrations  is  a 
top-down  analysis  such  as  that  described  by  Schorrc  (7| 
or  Conway  [8J.  As  soon  as  a mareo  delimiter  is  recognized, 
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thv  ir.iii.'lator  goes  into  a special  macro  scanning  mode 
it.  which  the  u>t ....  >e.i. antic  operations  tire  suppressed, 
ai.«l  a iiterfu  -.  r;i._  is  generated  for  each  metavariable  in 
• In'  structure.  At  the  conclusion  of  macro  recognition,  the 
source  text  is  modified  according  to  the  macro  definition, 
and  the  resulting  text  T replaces  the  original  text  in  the 
source  siring;  scanning  now  proceeds  again  starting  at  the 
tie"  inning  of  T.  Some  advantages  of  the  parsing  method 
aim  syntax  notation  adopted  here  arc:  (1)  syntax  is 
rec  ignition-oriented;  (2)  options  arc  easy  to  specify; 
and  (Mi  ambiguity  is  eliminated  by  virtue  of  the  factor- 
ing or  no  backup  principle. 

There  is  a [>ossiblc  danger  of  conflict  of  identifiers  after 
the  macro  has  been  expanded,  for  example  if  any  of  the 
expressions  used  in  a eall  on  the  sum  function  would  refer 
to  a free  variable  named  /.  This  conflict  is  avoided  if 
idem,  tiers  and  labels  are  cjualificd  by  their  block  numbers 
in  an  internal  representation  while  the  macros  are  being 
scanned. 

Conditional  Macro  Generation 

Macro  structures  may  contain  options  or  alternatives 
which  may  be  used  for  conditional  macro  generation.  As 
an  example,  consider  a slightly  more  complicated  for 
statement: 

Mimcro  for  variable  «—  express  {while  express'  |[by  express']  to 

exprcss'l 

<lo  statement 

An  option  or  alternative  is  called  a group;  groups  are 
numbered  from  left  to  right  as  shown;  i.e.,  a new  number 
occur*  ju-t  before  each  j,  ],  and  ) character.  Metavariables 
arc  ai'O  numbered  from  left  to  right. 

Associated  with  each  group  in  the  macro  structure  is  a 
corresponding  group  in  the  definition.  Each  definition 
group  is  delimited  by  braces,  and  is  referenced  by  the 
ordinal  number  of  the  corresponding  structure  group. 
Definition  groups  may  appear  in  any  order,  with  repeti- 
tion allowed. 

If  a group  is  recognized  during  a scan  of  the  macro 
-I met ure,  its  corresponding  definition  group  is  scanned; 
otherwise  the  group  is  bypassed.  One  possible  macro 
definition  of  the  given  for  statement  is  shown  below 

ilefme  iicgin  7,1 : SI  «—  S2; 

L'2:  if  (1  S3  then  begin  SC;  go  toLlj 

|3  SI  £ Si  then  begin  $6; 

SI  — SI  + (2  SI  1 1-1-2  Hi  go  to  1,2) 

end 

end 

einhnacro 

The  notation  j —in  • • • ) means  that  if  the  nth  group  is 
nr,;  recognized  during  scan  of  the  structure,  the  definition 
group  l-  scanned;  otherwise  it  is  bypassed. 

I tuple nu’iitatioil 

A syni.ix-m.nTO  translator  has  been  implemented  as 
part  of  .hi  experimental  simulation  language  under  dcvel- 
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opment . The  translator  utilizes  an  interpretive  language 
to  define  the  syntax  of  the  given  base  language. 

The  macro  recognition  and  generation  is  performed  bv 
a small  set  of  string  manipulation  routines  written  iii 
Eohthax*.  These  routines  perform  the  following  function-; 

Initialize  siring  pool  (link  up  string  elements). 

Create  a siring  (unlink  first  clement  in  pool  and  point  to  it). 
Destroy  a string  (return  siring  to  pool). 

Add  value  to  a string  (unlink  first  element  in  pool,  store  value  in 

it  and  append  to  string). 

Add  string,  to  stringi  (concatenate  stringj  to  stringi  without 

copying). 

Head  next  clement  in  string  (pointer  advances). 

Is  string  exhausted?  (has  pointer  advanced  to  end  of  string?) 

Concluding  Remarks 

The  development  of  syntax-directed  compilers  has 
eased  the  task  of  producing  scanners  for  different  pro- 
gramming languages.  Unfortunately,  the  specification  of 
semantics  has  proved  to  be  a more  difficult  problem.  The 
present  approach  attempts  to  solve  this  problem  by 
defining  extensions  in  terms  of  semantics  already  provided 
in  the  base  language.  This  avoids  the  rcspocificaiion  of 
syntax  and  semantics  for  the  kernel  of  each  new  special 
language,  assuming  they  have  a common  base.  This  ap- 
proach pays  off,  because  an  underlying  uniformity  of 
structure  can  be  shared  by  a large  class  of  special  purpose 
languages. 

Other  advantages  of  syntax-macros  are; 

1.  Flexible  format  allows  convenient  language  ex- 

tension. 

2.  Multiple  levels  of  definition  arc  possible. 

3 Macro  parameters  can  be  any  syntactic  element 
defined  in  the  base  language. 

4.  Special  separators  are  not  required  for  macro 
parameters. 

While  syntax-macros  allow  a flexible  format,  they  still 
have  essentially  a prefix  format  which  rules  out  the  han- 
dling of  infix  operators.  This  limitation,  which  probably 
could  be  removed  by  a more  general  approach,  is  certainly 
one  of  the  first  things  that  should  be  treated  in  any  ex- 
tension. 

The  type  of  conditional  macro  generation  described  i.t 
this  paper  does  not  provide  the  full  power  of  compilc-tiir'* 
imperatives,  since  descriptive  ability  has  been  empha- 
sized, rather  than  programming  orientation.  The  macro 
facility  described  above  should  also  allow  repetition  over 
lists  [4]  in  order  to  increase  descriptive  power. 

The  relative  ease  or  difficulty  of  performing  extensions 
of  a base  language  is  a function  of  the  choice  of  primitives 
in  the  base  language.  The  really  difficult  problems  in  the 
development  of  programming  languages  arc  those  of 
representation,  data  structuring,  and  storage  allocation. 
It  is  clear  that  these  problems  will  not  be  solved  by  syn- 
tactic methods  alone.  However,  it  is  hoped  that  the  ap- 
proach outlined  in  this  paper  can  be  usixl  in  conjunction 
with  other  formalisms  in  a combined  attack  on  the  prob- 
lems of  improving  programming  languages. 
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an  effective  data  processing  technique.  The  physical  reali- 
zation of  this  concept  has  been  seen  to  be  highly  modular 
and  suitable  for  programming  implementation. 

The  Data  Filter  behaves  as  a two-port  data  filter  within 
an  interpretive  processing  environment,  and  represents  the 
physical  realization  of  the  data  filtering  concept.  This  is 
accomplished  by  associating  format  declarations  with  its 
input  and  output  ports  which  define  its  processing  charac- 
teristics. The  desired  data  string  is  sequentially  constructed 
in  the  OUT  buffer  by  filtering  datum  in  the  IX  or  HOLD 
buffers  through  these  format  declarations.  A Procedural 
Umit roller  is  employed  to  synchronize  loading  of  the  IX 
buffer  and  dumping  of  the  OUT  buffer  to  achieve  specific 
flat  a processing  results  as  implied  by  the  job  being  proc- 
essed. 
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Algorithms  Policy  os  revised  in  August,  1966  to  include 
FORTRAN  appears  on  page  823. 

ALGORITHM  292 

REGULAR  COULOMB  WAVE  FUXCTIOX3 
Walter  Gautsciu  (Reed.  S Oct.  19Go) 

Purdue  University,  Lafayette,  Indiana  and  Argonne 
Xatioua!  Lalioratory,  Argonne,  Illinois 

Work  performed  under  the  auspices  of  the  U.  S.  Atomic  Energy  Commission, 
real  procedure  ((;/);  value  ;/;  real  y; 

comment  This  procedure  evaluates  the  inverse  function  ( = tly) 
of  1/  - tint  in  the  interval  ;/  g — 1/e,  to  an  accuracy  of  about 
4 percent,  or  belter.  Except  for  the  addition  of  the  ease 
— 1/e  S y S 0,  and  an  error  exit  in  case  y < — 1/c,  the  procedure 
is  identical  wit  It  the  real  procedure  t of  Algorithm  236; 
begin  real  p, 

if  y < — .367SS  then  go  to  alarm  1; 

if  V £ 0 then  l : = .367SS  + 1.0422  X sqrt(y  + .367SS)  eDe 

if  y S 10  then 
begin 

p : = .000057941  X y - .00176148;  p : = y X p + .020S045; 
p:=VXp-  .129013;  p ■=  y X p + .85777; 

<:«  y X p + 1.0123 
end 
else 
begin 

z :=  ln(y)  — .775;  p :=  ('.775-In(z))/(l-t-z); 
p :=  l/(l+p);  t y X p/z 

end 
end  t; 

procedure  minimal  (eta,  omega,  cps,  lal,  dm); 

value  eta,  omega,  cps;  real  etc,  omega,  cps,  la  1.  dm; 
comment  This  procedure  assigns  the  value  of  A/  to  lal,  accu- 
rately to  within  a relalive  error  of  cps,  where  |AU)  is  the  minimal 
solution  (normalized  by  Ao'  = I)  of  the  difference  equation 


2 L + 1 IS  4-  rf 

Xi’‘“TTT“Xl  ~Z(Z“+1}X^' 


0 (u  ^ 0). 


(For  terminology,  see  (31.)  If  I AH  denotes  the  solution  corre- 
sponding to  initial  values  Ao  = 1.  Ai  = u — g,  the  procedure  also 
assigns  to  dm  the  value  A,  — A,'.  The  negative  logarithm  of 
[A,  — A|'|  may  be  considered  a measure  of  the  “degree  of  mini- 
mality” of  the  solution  {At); 
begin  integer  nn,  real  cta'2,  r,  ra; 
eta 2 :«=  eta  f 2; 
nu  : = 20;  ra  :=  0; 

LI:  r :*=  p; 

for  L :=*  nu  fflqi  —1  tinlil  1 <lo 

r -lL12+ctu2)/(LX((2XL+\)Xomcya-(L+\)Xr))i 
if  abn(r-ra)  > cps  X ahs(r)  llicii 
begin 

ra  :«*  r;  nu  :*  nu  4*  10;  go  to  IA 

Cinl  j 

fnl  :*,r;  dm  :*  omega  — eta  — r 
end  minimal’, 
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Building  a mobile  programming  system 

W.  M.  Waite* 

* Department  of  Electrical  Engineering,  University  of  Colorado,  Boulder,  Colorado,  U.S.A. 


The  techniques  of  abstract  machine  modelling  and  macro  processing  can  be  used  to  develop  programs 
of  great  mobility.  This  paper  describes  the  concepts  and  construction  of  a system  which  has  been 
implemented  on  nine  different  computers.  In  no  case  was  more  than  one  man-week  required,  and  most 
implementations  went  more  rapidly  than  that. 
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1.  Introduction 

The  mobility  of  a program  is  a measure  of  the  ease  with 
which  it  can  be  implemented  on  a new  machine.  A user 
of  a highly  mobile  program  suffers  minimum  disruption 
of  his  work  when  his  computer  is  upgraded  or  he  moves 
to  a new  installation.  Because  his  program  is  mobile, 
only  a small  amount  of  effort  is  required  to  get  it  running 
on  the  new  machine  before  he  can  continue  using  it. 
Applications  programs  written  in  high  level  languages 
such  as  FORTRAN,  ALGOL  or  COBOL  have  reason- 
able mobility,  provided  that  the  author  has  taken  some 
pains  to  avoid  local  idiosyncrasies.  For  systems  soft- 
ware. however,  the  picture  is  much  grimmer.  There 
have  been  many  attempts  to  devise  high  level  languages 
for  compiler  w riting  (Feldman  and  Gries,  1968)  and  a 
few  to  use  such  languages  for  the  production  of  operating 
systems  (Glaser.  Coulcur  and  Oliver,  1965).  Unfortu- 
nately, none  of  these  attempts  has  yet  met  with  wioespread 
success. 

A FORTRAN  user  requires  a large  programming 
system,  consisting  of  the  compiler  and  associated  run- 
time routines.  The  mobility  of  his  programs  is  deter- 
mined by  the  number  of  installations  which  support  this 
system.  One  can  therefore  argue  that  the  mobility  of  a 
program  is  completely  dependent  upon  the  mobility  of 
the  programming  system  on  which  it  rests.  In  this  paper, 

I shall  discuss  a technique  which  I believe  is  fundamental 
to  the  improvement  of  programming  system  mobility.. 
The  background  and  general  concepts  from  which  the 
technique  was  derived  are  presented  in  Section  2,  while 
the  remainder  of  the  paper  is  concerned  with  a specific 
system  which  has  been  designed  and  built  using  this 
technique.  Section  3 describes  the  basic  bootstrap  on 
which  the  system  rests,  and  Section  4 discusses  the  im- 
plementation of  the  common  macro  processor.  The 
advantages  anil  disadvantages  of  the  approach  are  pre- 
sented in  the  Section  5. 

2.  General  approach 

The  technique  rewts  on  the  fact  that  it  is  possible  to 
identity  two  components  of  any  program:  the  basic 
operations  and  the  algorithm  which  coordinates  these 
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operations.  Given  a particular  task,  it  is  possible  to 
define  a set  of  basic  operations  and  data  types  needed  to 
perform  the  task.  These  operations  and  data  types 
define  an  abstract  machine — a hypothetical  computer 
which  is  ideally  suited  to  this  particular  task.  The  pro- 
gram to  perform  the  task  is  then  written  for  this  abstract 
machine.  To  run  the  program  on  a real  machine,  it  is 
necessary  to  realise  the  abstract  machine  in  some  way. 

The  abstract  machine  is  an  embodiment  of  the  basic 
operations  required  to  perform  a particular  task.  Theor- 
etically, it  has  no  connection  with  any  real  machine,  but 
practically  we  must  always  keep  a wary  eye  on  reality 
when  designing  an  abstract  machine.  Many  abstract 
machines  can  be  formulated  for  a given  task.  The  trick 
is  to  choose  one  of  the  right  ones.  Three  considerations 
must  be  kept  in  mind — 

1.  The  ease  and  efficiency  with  which  the  algorithm 
for  accomplishing  the  task  can  be  programmed  in 
the  language  of  the  abstract  machine. 

2.  The  ease  and  efficiency  with  which  the  simulation  of 
the  abstract  machine  can  be  carried  out  on  machines 
available  currently  and  in  the  forseeable  future. 

3.  The  tools  at  hand  for  the  realisation  of  the  abstract 
machine. 

Balancing  these  three  considerations  is  very  much  an 
engineering  task.  If  one  is  stressed  at  the  expense  of 
the  others,  there  will  be  trouble. 

Art  early  attempt  to  use  the  abstract  machine  concept 
was  the  UNCOL  proposal  (SHARE,  1958).  UNCOL 
was  to  be  a LWiversal  Computer  Oriented  Language 
which  w'ould  reduce  the  number  of  translators  for  n 
languages  and  m machines  from  n x nt  to  n -f~  m. 
Effectively,  the  UNCOL  proposal  created  a single  ab- 
stract machine.  In  view  of  the  three  considerations 
mentioned  above,  it  is  easy  to  see  why  this  attempt  was 
unsuccessful — try  to  design  an  abstract  machine  which 
comes  close  to  satisfying  condition  1 above  for 
FORTRAN,  LISP  (McCarthy,  I960)  and  SNOBOL 
(Griswold.  Poage  and  Polonsky,  1969)  simultaneously! 
The  mobile  programming  system  circumvents  this  diffi- 
culty by  allowing  a multiplicity  of  abstract  machines. 
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It  does  not  attempt  to  solve  the  n x »i  translator  prob- 
lem. The  advantage  of  the  mobile  programming  system 
lies  in  the  fact  that  it  reduces  the  specification  of  an 
algorithm  to  the  specification  of  its  basic  operations, 
thus  drastically  reducing  the  amount  of  effort  needed 
to  implement  it. 

One  way  to  carry  out  the  realisation  of  an  abstract 
machine  is  to  devise  for  it  an  assembly  language  whose 
statements  can  be  expressed  as  macros  acceptable  to  the 
real  machine’s  assembler.  This  approach  was  suggested 
by  Mcllroy  (1960)  and  used  in  the  implementation  of  L6 
(Knowlton,  1966)  and  SNOBOL  (Griswold,  el  ai.  1969). 
Unfortunately,  the  assemblers  for  different  machines  may 
require  quite  different  input  formats,  and  their  macro 
processors  often  vary  widely  in  power.  The  ease  of 
transferring  a program  written  in  this  way  thus  depends 
critically  on  the  existence  of  a suitable  assembly  language 
for  the  target  machine. 

Recent  developments  in  language-independent  macro 
processing  (Strachey,  1965,  Waite.  1967,  Brown,  1967) 
suggest  that  it  is  possible  to  make  available  a common 
macro  processor.  If  the  assembly  language  statements 
for  the  abstract  machine  are  acceptable  to  this  macro 
processor,  then  the  realisation  does  not  depend  upon  the 
macro  capabilities  of  the  target  machine,  but  rather  on 
the  availability  of  the  common  macro  processor.  An 
example  of  this  approach  is  the  implementation  of  WISP 
(Wilkes,  1964).  There  the  WISP  compiler  is  the  common 
macro  processor,  and  is  itself  built  up  by  bootstrapping 
from  simpler  macro  processors. 

3.  The  bootstrap 

One  of  the  design  goals  of  the  mobile  programming 
system  was  that  implementation  on  a new  machine  should 
not  require  a running  version  on  another  machine.  The 
base  of  the  system  was  to  be  easily  implemented  by  hand 
if  necessary.  Once  this  base  was  available,  it  could  be 
used  to  implement  a common  macro  processor  which 
would  handle  the  realisation  of  the  various  abstract 
machines  in  the  system.  The  common  macro  processor 
itself  was  written  in  the  assembly  language  of  an  abstract 
machine,  and  hence  the  base  of  the  system  must  include 
a simple  macro  processor. 

An  adequate  macro  processor  can  be  expressed  as  a 
91  statement  program  written  in  a restricted  form  as 
ASA  FORTRAN.  This  program,  known  as  SIMCMP, 
is  described  in  detail  by  Orgass  and  Waite  (1967). 
SIMCMP  is  written  in  FORTRAN  for  two  reasons: 

1.  Since  FORTRAN  is  a widely-used  language,  it  may 
be  available  on  the  target  machine.  This  means 
that  SIMCMP  can  be  implemented  trivially. 

2.  FORTRAN  was  originally  designed  to  be  quite 
close  to  machine  code,  and  hence  an  algorithm 
expressed  in  FORTRAN  is  easy  to  translate  to 
machine  code  by  hand.  (Translation  of  SIMCMP 
to  machine  code  for  two  different  machines  required 
about  4 man-hours  in  each  case.) 

The  primary  criterion  used  in  the  design  of  SIMCMP 
was  simplicity.  Only  those  features  considered  to  be 
absolutely  nccess.tr>  were  incorporated.  SIMCMP  has 
only  one  purpose:  to  realise  the  abstract  machine  used 
for  the  common  macro  processor.  This  approach  is  not 
the  one  which  has  been  taken  by  most  designers  of 
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mobile  systems,  who  prefer  to  assume  that  a working 
version  of  the  common  processor  is  already  available  on 
some  machine.  They  argue  that  if  a working  version  is 
available  on  machine  M,  then  a new  version  can  be 
created  on  machine  N by  the  following  procedure: 

1.  Code  macros  which  translate  the  source  code  of  the 
processor  to  the  assembly  language  of  N. 

2.  Expand  the  common  processor,  using  the  macros 
developed  in  (1)  and  the  processor  existing  on  M. 
The  result  is  an  assembly  language  program  for  .V. 

3.  Run  the  program  resulting  from  (2)  on  A'. 

I must  reject  this  procedure  on  the  basis  of  my  own 
experience.  More  often  than  not,  the  machines  M and 
/V  are  remote  from  one  another.  Since  it  is  viittially 
impossible  to  write  the  macros  correctly  the  first  lime, 
steps  (2)  and  (3)  must  be  iterated  and  the  distance  between 
the  machines  makes  this  a slow  and  costly  business. 
Also  the  machines  often  have  incompatible  peripherals 
and/or  different  character  sets:  at  each  iteration  of  (2) 
and  (3)  a tedious  translation  must  take  place. 

By  eliminating  the  need  for  a working  version,  SIM- 
CMP avoids  these  problems.  All  work  is  done  on  one 
machine.  The  abstract  languages  being  translated  are 
defined  using  a restricted  character  set  available  on  most 
machines  (43  characters  of  the  FORTRAN  set  on  the 
IBM  026  card  punch).  The  character  set  used  for  the 
real  machine's  assembly  language  is  completely  arbitrary. 
It  is  determined  by  the  macro  definitions,  which  arc 
written  specifically  for  that  machine  and  translated  on 
it.  This  is  not  true  for  the  procedure  outlined  above. 
There,  machine  Af  must  be  capable  of  writing  assembly 
code  for  machine  A'.  If  machine  Af  cannot  output  all 
of  the  characters  needed  by  the  assembly  language  of  .V, 
a translation  must  take  place  at  each  iteration  of  steps 
(2)  and  (3)  above.  On  the  other  hand,  suppose  that  all 
of  the  work  is  being  done  on  A'  using  SIMCMP.  If  A' 
cannot  recognise  all  of  the  43  characters  used  in  the 
abstract  language,  a translation  need  only  be  done  once 
to  put  the  source  code  into  an  acceptable  form. 

4.  The  common  macro  processor 

As  pointed  out  in  the  previous  section,  SIMCMP  was 
designed  primarily  for  simplicity  and  is  certainly  not 
adequate  to  serve  as  a common  processor  for  realising 
abstract  machines.  It  is  impossible  to  produce  good 
code  using  SIMCMP  because  decisions  cannot  be  made 
and  alternate  expansions  provided.  Because  there  is 
no  iteration  facility,  macros  with  argument  lists  of  in- 
definite length  cannot  be  handled.  A second  processor, 
known  as  STAGE2,  was  therefore  designed  as  the  common 
processor  for  the  system.  It  provides  all  of  the  features 
normally  associated  with  a general  purpose  macro  pro- 
cessor (Mcllroy,  1960).  In  many  respects,  it  is  quite 
similar  to  LIMP  (Waite.  1967).  Its  input  recognition 
procedure  is  language-independent,  employing  the  I IMP 
type  of  scanning  mechanism  to  recognise  macro  calls 
and  isolate  parameters.  The  code  body,  however,  differs 
from  that  of  LIMP.  It  does  not  include  the  “grouping" 
concepts  nor  the  SNOBOL  interpreter.  Conditional 
expansion,  iteration  and  the  like  arc  provided  by  pro- 
cessor functions  rather  than  by  an  explicit  program  struc- 
ture. The  ability  to  perform  different  parameter  con- 
versions has  been  retained  and  extended.  A complete 
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manual  describing  the  use  of  STAGE2  is  available 
(Waite,  1968). 

The  design  of  STAGE2  required  a balancing  of  two 
conflicting  objectives: 


2,4b  Translate,  assemble  and  run  the  test  programs. 
Correct  any  errors  in  the  macros  which  were 
detected,  and  repeat  step  (b)  until  no  errors 
remain. 


1.  It  must  be  translated  by  SIMCMP. 

2.  It  should  be  as  flexible  and  as  general  as  possible. 

My  overall  philosophy  dictated*that  (I)  should  be  given 
most  weight,  and  any  clear  choice  had  to  be  resolved  in 
favour  of  it.  Thus.  STAGE2  does  not  provide  all 
features  which  one  would  like  to  see  in  a macro  pro- 
cessor, it  is  relatively  slow,  and  it  requires  a fair  amount 
of  data  space.  Its  purpose  is  to  provide  a common 
macro  processor  for  realising  a variety  of  abstract 
machines,  and  not  to  act  as  a processor  for  day-to-day 
use  by  applications  programmers.  For  this  latter  use,  we 
are  preparing  versions  of  ML/1  (Brown,  1967)  and  LIMP. 

STAGE2  is  written  in  a language  called  FLUB  (First 
Language  Under  Bootstrap).  FLUB  has  28  machine 
operations  and  2 pseudo-operations,  each  of  which  can 
be  expressed  as  a macro  acceptable  to  SIMCMP.  A 
complete  description  of  the  characteristics  and  design 
of  the  FLUB  language  has  been  given  by  Waite  (1969). 
The  procedure  for  implementing  STAG E2  on  a new- 
machine,  TV,  is  thus: 

1.  Implement  SIMCMP  on  N. 

2.  Write  28>macro  definitions  which  translate  FLUB 
into  the  assembly  language  of  N. 

3.  Translate  STAGE2,  using  SIMCMP  and  the  defin- 
itions of  (2),  and  assemble  the  resulting  program. 

Once  STAGE2  is  running,  it  is  possible  to  rewrite  the 
28  macros,  taking  advantage  of  the  added  flexibility  of 
STAGE2.  Using  the  version  of  STAGE2  already  avail- 
able, an  optimised  version  of  STAGE2  can  thus  be 
produced: 

4.  Write  28  macro  definitions  which  translate  FLUB 
into  the  assembly  language  of  N.  These  macros 
use  the  features  made  available  by  STAGE2. 

5.  Translate  STAGE2,  using  the  version  of  STAGE2 
implemented  in  (l)-(3)  and  the  definitions  of  (4), 
and  assemble  the  resulting  program. 

The  operations  of  the  FLUB  machine  are  rather 
simple  to  describe  and  can  be  coded  in  a straightforward 
manner.  Unfortunately,  a well-known  axiom  in  com- 
puter programming  states  that  it  is  impossible  to  write 
even  the  simplest  code  correctly  the  first  time.  The 
macro  definitions  are  the  ‘hardware’  of  an  abstract 
machine,  and  an  incorrect  macro  definition  is  analogous 
to  a writing  error  in  a real  computer.  No  manufacturer 
tests  a computer  just  o(T  the  production  line  by  running 
a batch  of  FORTR  AN  jobs  through  it.  and  the  implemen- 
tor of  an  abstract  machine  should  not  be  forced  to 
attempt  a similar  feat.  Two  test  programs  have  been 
developed  by  Mr.  E.  H.  Henningerand  Mr.  R.  C.  Dunn 
to  facilitate  checkout  of  the  macros.  These  test  pro- 
gra  us  were  quite  tedious  to  construct,  and  arc  subject 
to  most  of  the  problems  of  normal  hardware  test  pro- 
grams (Bashkow.  Fricts  and  Karson,  1962). 

Using  the  test  programs,  steps  (2)  and  (4)  above  have 
two  sub-steps: 

•1,4a  Write  28  macro  definitions  which  translate 
FLUB  into  the  assembly  language  of  /V. 


Testing  the  macros  in  this  manner  simplifies  and  speeds 
the  implementation  considerably,  because  it  means  that 
the  implementor  need  not  be  familiar  with  the  inner 
workings  of  STAGE2  to  be  able  to  debug  his  macros. 
Since  the  test  programs  were  made  available,  STAGE2 
has  been  implemented  on  six  different  machines.  Four 
of  those  implementations  were  done  by  people  who 
were  not  familiar  with  STAGE2.  but  in  no  case  was 
such  familiarity  needed.  The  test  programs  detected  all 
of  the  macro  coding  errors,  and  STAGE2  ran  perfectly 
when  compiled. 

I cannot  overstress  the  importance  of  a comprehensive 
macro  test  program  in  the  successful  implementation  of 
a machine  independent  system.  Macro  coding  errors 
can  be  very  subtle,  requiring  hours  of  debugging  to 
trace  them  down  if  the  machine  independent  program  is 
the  only  test  case.  A conservative  estimate  based  on 
our  experience  is  that  lack  of  a good  test  program  will 
increase  the  time  required  to  complete  an  implementation 
by  a factor  of  five  when  the  author  of  the  system  is 
available  to  debug  the  macros.  When  he  is  not  avail- 
able, the  task  is  almost  hopeless. 


5.  Advantages  and  disadvantages 

Use  of  the  abstract  machine  concept  allows  an  im- 
pressive reduction  in  the  amount  of  coding  necessary  to 
establish  a processor  on  a new  machine.  In  the  case  of 
SNOBOL4  (Griswold,  el  al.,  1969),  for  example,  he 
compilcr/interpreter  contains  roughly  4500  lines  of  cole, 
but  only  approximately  100  primitives  must  be  recoded 
for  a new  machine.  The  FLUB  machine  has  28  prim- 
itives. and  STAGE2  is  over  850  FLUB  statements.  A 
LISP  (McCarthy.  1960)  system  without  numeric  capa- 
bilities requires  just  8 primitives  operating  on  6 data  types. 
Although  the  reduction  in  sheer  bulk  of  coding  is  a 
factor  in  the  success  of  this  approach,  the  decrease  in 
code  complexity  is  more  significant.  Each  primitive 
can  be  specified  thoroughly,  and  is  generally  quite  easy 
to  implement. 

Whenever  the  term  'machine  independence’  is  men- 
tioned, questions  of  efficiency  are  bound  to  arise.  Ot 
course,  a program  implemented  as  described  in  this 
paper  will  not  be  as  fast  and  tight  as  a hand-coded 
version.  Two  arguments  can  be  brought  to  bear,  how- 
ever. First,  extreme  efficiency  of  the  generated  code 
may  not  be  an  issue,  as  long  as  extreme  inefficiency  is 
avoided.  An  • interactive  BASIC  (Dartmouth,  1966) 
system  which  can  be  up  and  running  with  less  than  one 
man-week  of  effort  may  be  preferable  to  one  which  runs 
twice  as  fast  but  requires  10  man-months  to  complete. 
Second,  it  is  possible  to  optimise  the  program  on  several 
levels.  The  source  language  is  designed  to  match  the 
problem  well,  and  a great  deal  of  time  can  be  put  into 
producing  an  efficient  program  for  the  abstract  machine. 
Careful  construction  of  the  macros  can  result  in  sur- 
prisingly good  code  for  the  target  machine.  Once  the 
assembly  language  version  is  available,  critical  parts  can 
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be  rewritten  at  leisure  to  further  improve  the  program’s 
performance. 

In  addition  to  SIMCMP  and  STAGE2,  a comprehen- 
sive text  manipulation  program  and  two  small  editors 
have  been  produced  using  the  system  described  in  this 
paper.  We  are  currently  working  on  interactive  BASIC 
(Dartmouth,  1966)  and  SNOBOL4  (Griswold,  et  a!., 
1969).  A ‘logic  analyser’  (which  includes  automatic 
flowcharting)  and  a paginator  for  producing  reports  are 
in  the  planning  stage.  The  list  processors  WISP  (Wilkes, 
1964),  LISP  (McCarthy,  1960)  and  L6  (Knowlton,  1966) 
are  being  considered. 

The  system  has  proved  extremely  mobile  in  practice, 
having  been  implemented  on  nine  different  machines.  In 
each  case  the  total  effort  was  less  than  one  man-week, 
and  most  went  more  rapidly  than  that.  A team  of  two 
people,  one  thoroughly  familiar  with  the  system  and  the 
other  with  the  target  machine,  have  had  it  running  in 
one  day. 
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Hcre  an  unconditional  statement  plus  a conditional  expres- 
sion lias  become  a conditional  statement. 

Fortunately  both  of  these  situations  have  been  ruled  out 
by  Section  4.7. 5.2. 

Conclusion 

For  centuries  astronomers  have  given  the  name  Algol  to 
a star  which  is  also  called  Medusa’s  head.  The  author  has 
tried  to  indicate  every  known  blemish  in  [2];  and  he  hopes 
that  nobody  will  ever  scrutinize  any  of  his  own  writings  as 
meticulously  as  he  and  others  have  examined  the  Algol 
Report. 
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Tlie  ML /I  Macro  Processor 

?.  J.  Brown 

University  Mathematical  Laboratory,  Cambridge,  England 

A general  purpose  macro  processor  called  ML/'I  is  described. 
ML /I  has  been  implemented  on  the  PDP-7  and  I.C.T.  Atlas  2 
computers  and  is  intended  as  a tool  to  allow  users  to  extend 
any  existing  programming  language  by  incorporating  new 
statements  and  other  syntactic  forms  of  their  own  choosing 
and  in  their  own  notation.  This  allows  a complete  user-oriented 
language  to  be  built  up  with  relative  ease. 

Introduction 

A macro  is  basically  a means  of  extending  an  existing 
programming  language,  called  the  base  language,  by  intro- 
ducing a new  syntactic  unit  which  is  describable  in  terms  of 
the  existing  syntactic  units  of  the  base  language.  This 
paper  is  concerned  only  with  macro  processors  which 
operate  on  text  and  act  as  a preprocessor  to  the  compiler 
for  the  base  language.  Most  existing  macro  processors  have 
a fixed  base  language,  usually  an  assembly  language,  and 
the  macro  processor  and  the  base  language  processor  are 
regarded  us  a single  piece  of  software,  as  exemplified  by  the 
term  “macro-assembler.”  One  of  the  best  knowD  macro- 
assemblers is  Macro  Fap’[1].  Most  macro-assemblers  re- 
quire that  macros  expand  into  a series  of  statements;  it  is 
not  possible,  for  instance,  to  use  a macro  to  generate  the 
address  field  of  an  instruction. 

As  a very  elementary  example  of  the  use  of  a typical 
macro  assembler,  assume  that  a user  wished  to  introduce 
a tingle  statement  that  would  move  an  item  from  one 
storage  location  to  another  on  a macliine  that  required  two 
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instructions  to  achieve  this.  To  do  this  he  would  define  a 
macro,  give  it  a name,  MOVE,  say,  and  define  the  two 
requisite  instructions  as  the  replacement  text  of  the  macro. 
Having  defined  his  macro,  the  user  could  then  treat 
MOVE  as  if  it  were  an  assembly  language  statement,  and 
the  macro  processor  would  expand  this  into  the  two  given 
instructions.  The  MOVE  statements  are  called  macro  calls 
and  have  form: 

I 

MOVE  argument  1,  argument  2 

In  the  typical  macro -assembler  the  syntax  of  macros  is 
very  rigid.  Each  line  of  input  text  must  be  either  a state- 
ment in  the  base  language  or  a macro  call.  The  arguments 
of  macro  calls  are  separated  by  a fixed  delimiter,  the 
comma,  and  the  closing  delimiter  (the  symbol  used  to 
indicate  the  end  of  a call)  is  typically  either  a space  or  the 
end  of  a line. 

Several  macro  processors  with  more  general  properties 
than  the  basic  macro-assembler  have  been  produced. 
Among  these  are  XPOP  [2],  Wisp  [3],  Limp  [4],  GPM  (5] 
and  True  [6].  These  have  extended  the  basic  concept  in  two 
main  ways.  Firstly,  the  user  has  been  allowed  to  define  Vs 
own  notation  for  writing  macro  calls.  This  rotation  might, 
for  instance,  be  something  approaching  the  English  lan- 
guage or  alternatively  might  be  close  to  the  language  of 
algebra.  Secondly,  the  macro  processor  has  been  made  in- 
dependent of  the  base  language  and  its  processor.  In  this 
case  the  same  macro  processor  can  act  as  a preprocessor  to 
any  number  of  different  languages,  and  there  is  no  restric- 
tion on  the  syntactic  forms  of  the  base  language  which 
may  be  expanded. 

ML/I  incoipo rates  both  of  these  extensions  and  is 
intended  to  allow  the  user  to  extend  any  language,  using 
his  own  notation.  The  only  restriction  on  notation  is  that 
macro  calls  must  commence  with  the  macro  name.  ML/I 
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recogirizes  a macro  by  the  occurrence  of  its  name  and  a 
macro  call  is  taken  as  the  text  from  the  macro  name  up  to 
its  closing  delimiter.  This  contrasts  with  macro  processors 
such  as  Wisp  and  Limp  where  macro  calls  are  recognized 
by  comparing  each  line  of  input  text  with  a number  of 
templates. 

Main  Features  of  ML/I 

This  paper  will  not  attempt  to  give  a detailed  description 
of  ML/I  but  rather  will  describe  its  main  features.  For  de- 
tails the  reader  is  referred  to  the  User’s  Manual  [7].  Firstly, 
the  general  form  of  a macro  will  be  described  together  with 
examples  of  its  applications.  ML/I  allows  any  sequence  of 
characters  to  be  used  for  each  delimiter.  The  macro  name 
is  legarded  as  delimiter  number  zero.  Hence  the  user  could 
specify  TO  and  a semicolon  as  delimiters  of  his  MOVE 
macro  and  write  his  calls: 

MOVE  argument  1 TO  argument  2 ; 

though  this  in  itself  could  hardly  be  claimed  as  a dramatic 
improvement.  The  special  feature  of  ML/I  is  that  the  user 
specifies  a delimiter  structure  for  each  macro  which  makes 
it  possible  for  each  macro  to  have  any  number  of  alterna- 
tive patterns  of  delimiters.  The  purpose  of  the  delimiter 
structure  is  to  define  the  name  or  names  of  the  macro  and 
to  define  for  each  delimiter  a successor  or  set  of  alternative 
successors.  A successor  is  the  next  delimiter  to  be  searched 
for  when  scanning  a call.  A closing  delimiter  may  be  con- 
sidered as  having  a null  successor.  As  an  example,  con- 
sider an  IF  macro  which  has  alternative  forms: 

ta)  IF  argument  1 = argument  2 TIIEX  argument  3 EXD 
or  (b)  IF  argument  1 =•  argument  2 TIIEX  argument  3 ELSE 
argument  4 EXD 

In  the  delimiter  structure  of  this  macro  each  delimiter  has 
a unique  successor  except  for  the  delimiter  THEX  which 
has  the  alternative  successors  EXD  and  ELSE. 

The  above  IF  macro  could  be  extended  by  allowing  as 
the  first  delimiter  a number  of  alternative  relational  opera- 
tors to  “equals."  This  could  be  done  by  specifying  the  set 
of  relational  operators  as  alternative  successors  to  IF. 
Each  relational  operator  would  have  THEX  as  its  suc- 
cessor. In  order  that  a meaning  can  be  ascribed  to  different 
delimiter  names,  ML/I  contains  a facility  for  placing 
conditional  statements,  operative  at  macro  generation 
time,  within  the  replacement  text  of  a macro.  These  condi- 
tional statements  can  be  used  to  make  the  form  of  the  code 
replacing  a macro  call  dependent  on  the  delimiters  used  in 
the  call. 

Delimiter  structures  can  be  designed  to  allow  macros 
with  an  indefinitely  long  list  of  arguments.  Assume,  for 
example,  that  it  is  desired  to  extend  further  the  IF  macro 
by  allowing  between  IF  anti  THEX  a whole  series  of  rela- 
tions connected  by,  say,  AXD  or  OR.  This  could  be 
achieved  by  defining  the  successors  of  each  of  the  relational 
operators  to  be  AXD,  OR,  or  THEX.  The  successors  of 
CR  and  AND  would  be  the  set  of  relational  operators,  thus 
causing  the  delimiter  structure  to  loop  back  on  itself. 


ML/I  allows  macro  calls  to  be  nested  within  the  argu- 
ments of  other  macro  calls.  Hence  it  would  be  quite  possi- 
ble to  write  nested  calls  of  the  IF  macro.  The  method  of 
searching  for  delimiters  takes  care  of  nested  calls. 

Before  the  more  basic  details  of  ML/1  are  described,  a 
few  more  examples  of  its  applications  will  be  considered  in 
general  terms  in  order  that  the  reader  may  get  some  sort  of 
a feel  for  the  kind  of  macro  that  is  normally  defined. 

Example  1.  It  is  possible  to  design  a set  of  macros  that 
would  be  useful  for  referencing  individual  fields  in  blocks 
of  data.  Thus  FIELD  and  SET  macros  could  be  designed 
that  would  allow  the  user  to  define  the  fields  of  his  data 
blocks  and  then  to  refer  to  these  fields.  His  program  might 
read  (where,  for  the  sake  of  clarity,  the  delimiters  of  the 
FIELD  macro  have  been  italicized)  : 

FIELD  FATHER  IS  WORD  1 ; 

FIELD  MOTHER  IS  WORD  3 ; 

FIELD  AGE  IS  BITS  6 TO  12  OF  WORD  4 ; 

SET  X = AGE(FATHER(MOTIIER(Y)  ) ); 

The  action  of  the  FIELD  macro  would  be  to  sei  up  a 
macro  definition  whose  name  was  derived  from  the  first 
argument  of  FIELD.  Thus  the  third  call  of  FIELD  would 
define  a macro  with  name  “AGE(”  and  with  closing  de- 
limiter “)”.  The  replacement  text  of  this  macro  would 
generate  code  to  reference  the  desired  field  of  the 
designated  data  block. 

Example  2.  It  is  possible  to  write  a macro  of  form: 

LOAD  argument  ; 

where  the  argument  is  a general  arithmetic  expression. 
This  macro  would  generate  code  to  load  the  value  of  the 
arithmetic!  expression  into  an  accumulator.  The  argument 
could  be  analyzed  by  defining  the  character  “(”  as  t.  macro 
name  with  a right  parenthesis  as  its  closing  delimiter  and 
specifying  all  the  permissible  arithmetic  operators  for  the 
intervening  delimiters,  of  which  there  could  be  any  number. 

Since  ML/I  is  independent  of  the  base  language,  it  is 
intended  that  it  be  used  as  a common  preprocessor  to  all 
the  compilers  and  assemblers  available  at  an  installation, 
in  the  same  way  as  each  compiler  and  assembler  might  use 
a common  loader.  In  general  it  is  true  to  say  that  the  higher 
level  the  language,  the  less  need  there  is  for  macro  facilities. 
However,  even  in  the  most  comprehensive  high-level  lan- 
guages, macros  are  useful  for  introducing  statements 
specially  designed  for  the  user’s  particular  field  of  applica- 
tion. 

The  above  examples  have  illustrated  the  primary  use  of 
ML/I,  namely  to  allow  any  existing  programming  lan- 
guage to  be  extended  to  suit  a particular  user’s  require- 
ments. This  form  of  extension  could  be  carried  to  the  level 
where  the  extended  language  could  be  considered  as  a 
language  in  its  own  right. 

The  efficiency  of  code  generated  by  ML/I  depends  how 
well  the  macros  are  designed.  There  are  macro-time  vari- 
ables and  conditional  facilities  to  help  eliminate  the  sort  of 
inefficiencies  that  occur  at  boundaries  between  macros. 
As  regards  speed,  ML/I  would  be  considerably  slower  than 
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ft  special  purpose  compiler  for  a language.  \'otc,  however, 
that  it  is  not  Intended  to  be  a general  purpose  compiler. 
Instead  of  designing  a new  language  and  writing  a compiler 
for  it ; the  idea  is  for  the  tvser  to  start  at  the  other  end,  as  it 
were,  and  extend  itrt  existing  language  to  meet  his  require- 
ments. 

The  usefulness  of  ML/I  is  not  confined  to  language 
extension.  It  run  also  be  used  for  some  applications  in  text 
editing.  For  instance,  it  is  now  being  used  as  an  aid  to 
converting  front  Fortran  IV  to  a dialect  of  Fortran  II. 
Here  ML/I  performs  the  transformations  of  which  it  is 
capable,  for  instance  recognizing  declarations  of  logical 
variables  and  converting  statements  involving  them  into 
corresponding  arithmetic  statements.  In  those  cases  where 
it  cannot  perform  the  required  transformation  it  places  a 
special  marker  beside  the  Fortran  IV  statement. 

Introductory  Details  of  ML/I 

ML  H is  fed  some  source  text.  It  performs  some  trans- 
formations on  this  text  and  generates  some  output  text, 
which  is,  in  turn,  normally  fed  to  some  compiler  or  as- 
sembler. These  transformations  are  specified  by  construc- 
tions, which  are  usually  defined  at  the  start  of  the  source 
te.M.  The  most  important  type  of  construction  is  the 
ntacro. 

The  character  set  of  ML/I  will  vary  between  implemen- 
tations but  it  should  contain  the  letters  and  numbers  and 
some  punctuation  characters.  A punctuation  character  is 
any  character  that  is  not  a letter  or  number.  “Space”  or 
“blank”  is  treated  as  a punctuation  character  and  it  is 
usually  convenient  to  assume  there  is  a character  called 
“newline”  at  the  end  of  each  line  of  text.  (This  character 
physically  exists  if  input  is  from  paper  tape.  In  the  case  of 
card  input  it  would  have  to  be  specially  inserted  by  the 
input  routine.)  However,  in  this  paper,  for  reasons  of 
layout,  it  will  be  assumed  that  “newline”  is  not  a charac- 
ter. .ML/I  treats  text  as  a sequence  of  atoms  rather  titan 
as  a sequence  of  individual  characters.  An  atom  is  defined 
as,  a single  punctuation  character  or  a sequence  of  letters 
and,  or  numbers  surrounded  by  punctuation  diameters. 
Thus  the  piece  of  text  which  follows  consists  of  the  six 
atoms;  comma,  DOG,  space,  23,  plus,  and  C8. 

,DOG  23+C8 

Any  sequence  of  atoms  may  be  defined  as  the  name  of  a 
construction  or  as  the  name  of  any  of  the  other  delimiters. 
In  general  every  time  the  name  of  a macro  is  encountered 
during  the  scanning  of  text  it  is  taken  as  the  start  of  a 
macro  call  and  a search  is  made  for  the  remaining  delim- 
iter.-. The  same  applies  to  other  constructions.  Tims  if 
DOG  were  a macro  with  dosing  delimiter  plus,  then  the 
above  text  would  contain  a call  of  it.  However,  if  DO  were 
the  macro  name,  the  above  text  would  not  contain  a call  of 
it  since  DO  is  not  an  atom  of  t he  text. 

The  paragraphs  which  follow  describe  the  other  types  of 
construction  m addition  to  macros. 


Inserts 

Consider  the  replacement  text  of  t lie  MOVE  macro 
which  lias  already  I icon  used  as  an  example.  (This  example 
and  some  subsequent  ones  will  Use  lM)l’-7  Assembly  Lan- 
guage. However,  it  is  not  assumed  that  the  reader  is  famil- 
iar with  the  CD  P-7  and  each  instruction  will  be  explained.) 
The  replacement  text  of  the  MOVE  macro  consists  of  the 
two  following  statements: 

LAC  argument  1 /Load  accumulator  with  first  argument. 

DAC  argument  2 /Deposit  accumulator  at  second  argument. 

It  is  necessary  to  indicate  to  ML/I  that  it  mast  insert 
the  appropriate  argument  at  the  appropriate  point,  '.'his  is 
done  by  a construction  called  an  insert  which  has  a name 
and  a closing  delimiter.  It  will  be  assumed  in  the  rest  of 
this  paper  that  the  character  has  been  defined  as  an 
insert  name  with  a period  as  its  dosing  delimiter.  Between 
the  insert  name  and  its  delimiter  a designation  is  written 
to  indicate  what  to  insert.  In  particular,  “A”  stands  for 
argument.  The  replacement  text  of  MOVE  would  be 
written: 

LAC  :A1. 

DAC  :A2. 

Several  other  elements  in  addition  to  arguments  may  be 
inserted  and  these  are  described  later. 

Skips 

It  may  be  that  the  user  doe-  not  wish  certain  occurrences 
of  macro  names  in  his  text  to  be  taken  to  mean  the  macro 
is  to  be  called.  This  might  apply,  for  instance,  within  com- 
ments or  character  string  literals.  In  this  ca-e  skips  are 
used  to  inhibit  macro  replacement  within  the  required 
context.  Thus  if  the  base  language  were  PL/I  a -kip  name 
with  closing  delimiter  "*  ” might  be  defined,  since 
these  characters  arc  used  to  enclose  PL  T comments.  Each 
skip  has  an  associated  set  of  options  which  determine 
whether  the  skip  is  to  be  copied  to  the  output  text  or 
deleted  during  macro  expansion.  It  is  possible  to  copy  the 
delimiters  and  delete  the  intervening  text  or  vice  versa.  In 
most  applications  the  u-er  will  require  a special  skip  name 
and  closing  delimiter  called  literal  brackets.  The  options  for 
literal  brackets  are  set  so  that  the  brackets  are  deleted  but 
the  intervening  text  is  copied  literally  to  the  output  te\* 
It  will  be  assumed  in  the  rest  of  this  paper  that  the  charac- 
ters “(”  and  “)”  have  been  defined  as  literal  brackets. 
With  this  assumption,  an  occurrence  of  (DOG)  in  the 
source  text  would  give  rise  to  DOG  in  the  output  text 
irrespective  of  whether  DOG  was  a macro  name. 

Warning  Markers 

In  some  applications  it  is  inconvenient  to  have  every 
occurrence  of  a macro  name  outside  a skip  taken  as  the 
beginning  of  a rail.  In  these  cases  ML/I  can  be  placed  in 
warning  mode  by  defining  some  atom  as  a warning  marker. 
If  ML/I  is  in  warning  mode  all  macro  calls  must  be  pre- 
ceded by  a warning  marker  and  all  macro  names  not  pre- 
ceded bv  a warning  marker  arc  treated  literally.  It  ML/I 
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i.>  not  in  warning  mode,  macro  names  arc  essentially  re- 
sen  ed  words  and  if  they  are  Used  for  any  other  purpose 
they  must  be  enclosed  :n  srdps.  It  will  be  assumed  in  exam- 
ples in  the  rest  of  tins  paper  that  ML/I  is  not  in  warning 
mode. 

Text  Evaluation 

The  environment  consists  of  all  the  constructions  defined 
by  the  user,  together  with  the  system  macros,  which  will 
be  described  later.  The  process  of  scanning  a piece  of  text 
to  expand  macro  calls  and  tleal  with  skips  and  inserts  is 
called  evaluating  the  text.  The  text  generated  as  a result  of 
this  evaluation  is  called  the  value.  The  value  of  a piece  of 
text  depends,  of  course,  on  the  environment. 

Constructions  may  be  nested  in  any  desired  way.  When 
ML/I  encounters  a macro  call,  it  evaluates  the  replace- 
ment text  in  the  same  way  as  it  evaluates  the  source  text. 
The  replacement  text  may  itself  contain  macro  calls  and 
recursion  is  permitted.  The  arguments  of  macros  are 
evaluated  when  they  are  inserted  rather  than  when  the 
call  containing  them  is  scanned.  Thus  they  are  “called  by 
name”  rather  than  “called  by  value.”  This  fact  is  useful  if 
ML,/ 1 is  generating  assembly  code  as  it  is  possible  to  exam- 
ine the  context  in  which  the  code  is  to  be  placed 
and  generate  optimal  code  accordingly. 

Macro  Variables 

ML/I  contains  some  “macro-time”  integer  variables, 
i.e.,  variables  operative  during  macro  generation.  There 
are  facilities  for  the  user  to  perform  arithmetic  on  these 
variables  and  to  insert  their  values  into  his  text.  There  are 
two  types  of  macro  variables  as  follows. 

Permanent  variables.  These  are  called  PI,  P'2,  etc.  They 
are  reserved  at  the  start  of  a program  and  remain  in  exist- 
ence throughout.  They  have  global  scope. 

j'emporary  variables.  These  arc  called  Tl,  T2,  etc. 
Each  time  a user-defined  macro  is  called,  a number  (de- 
fined by  the  user)  of  temporary  variables  is  allocated. 
These  are  local  to  the  current  call.  The  first  three  tem- 
porary variables  are  initialized  by  ML/I  in  the  following 
way : 

Tl  contains  the  number  of  arguments. 

T2  contains  the  number  of  macro  calls  performed  so 
far. 

T3  contains  the  current  depth  of  nesting  of  macro 
calls. 

The  initial  value  of  T2  is  a number  unique  to  the  current 
call  and  is  useful  for  generating  unique  labels.  If  the  re- 
placement text  of  a macro  contains  a label  it  is  imperative 
that  a different  name  be  generated  for  the  label  each  time 
the  macro  is  called.  This  can  be  achieved  by  writing  the 
label  as: 

LAB  :T2. 

(Remember  that  the  colon  is  assumed  to  be  an  insert  name 
in  this  and  all  subsequent  examples.)  A later  example 
illustrates  the  use  of  this  feature. 


Further  Facilities  for  Inserts 

It  has  been  seen  that  arguments  and  macro  variables 
may  be  inserted  into  text.  This  section  describes  the  com- 
plete facilities  offered  by  inserts. 

The  general  form  of  the  designation  of  an  insert  consists 
of  a flag  followed  by  a subscript  expression.  The  subscript 
expression  may  consist  simply  of  a positive  integer,  as  in 
the  previous  examples,  or  it  may  be  the  name  of  a macro 
variable  or  an  arithmetic  expression  involving  macro 
variables  and/or  constants.  Thus  if  Tl  had  its  initial 
value  then  ATI  would  reference  the  last  argument  and 
ATI-1  would  reference  the  next  to  last  argument.  The 
following  are  the  possible  flags  that  can  be  used  foi  inserts, 
together  with  a description  of  each : 

A.  — argument. 

D.  — delimiter. 

\VA,  \VD.  — argument  or  delimiter  in  its  written  form.  The  argu- 

ment or  delimiter  is  not  evaluated  but  is  inserted 
literally. 

null.  — the  numerical  value  of  the  subscript  expression  is 

inserted. 

L.  — macro  label.  This  type  of  insert  “places”  a macro- 

time label  which  may  be  the  subject  of  n macro-time 
GO  TO  statement;  it  is  a special  type  of  insert  iu  that 
it  does  not  cause  any  output  text  to  be  generated,  i.e  , 
its  value  is  null. 

Operation  Macros 

ML/I  contains  a number  of  built-in  macros  called  opera- 
tion macros.  Operation  macros  are  used  for  such  purposes 
as  defining  new  constructions,  performing  macro-time 
arithmetic  and  changing  the  position  of  scan  (using  the 
macro-time  GO  TO  statement).  The  names  of  operation 
macros  all  begin  with  the  letters  “MC”  so  that  they  may 
readily  be  differentiated  from  user-defined  macros.  An 
example  of  an  operation  macro  is  MCDEF,  which  is  used 
for  defining  macros.  This  has  form: 

MCDEF  argument  1 AS  argument  2 ; 

The  first  argument  must  be  in  the  form  of  a structure 
representation,  which  specifies  the  delimiter  structure  of 
the  macro  being  defined.  In  the  simplest  case,  where  all 
the  delimiters  are  fixed,  a structure  representation  is 
specified  by  writing  the  delimiters  in  the  order  in  which 
they  are  to  occur.  The  macro  name,  which  is  regai-dcd  as 
delimiter  number  zero,  comes  first.  The  second  argument 
of  MCDEF  specifics  the  replacement  text  of  the  macro 
being  defined.  Thus  if  “TO”  and  semicolon  were  chosen 
to  delimit  the  ends  of  the  two  arguments  of  MOVE,  its 
definition  would  be  written: 

MCDEF  MOVE  TO  ; AS 
< LAC  :A1. 

DAC  :A2. 

>: 

and  a call  of  form: 

MOVE  X TO  TABLE  + 6, 
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would  expand  into: 

LAC  X 

DAC  TABLE  + 6 

Note  that  the  replacement  text  of  MOVE  has  been  en- 
close i in  literal  brackets  in  the  above  definition.  This  is 
bora  i~c  all  arguments  to  operation  macros  arc  evaluated 
before  being  processed.  Assume  that  the  litcial  brackets 
laid  been  omitted.  Then  in  evaluating  the  second  argument 
of  MCDEF,  ML/I  would  have  tried  to  perform  the  inserts. 
This  would  have  unfortunate  results  since  the  inserts 
should  be  performed  when  MOVE  is  called,  not  when  it  is 
defined.  In  its  correct  form,  with  the  literal  brackets 
present,  the  evaluation  of  the  argument  leads  to  the  literal 
brackets  being  deleted  and  the  enclosed  text  being  copied 
literally.  This  text  then  becomes  the  replacement  text  of 
the  MONT  macro.  The  reader  is  probably  tempted  to  ask 
why  operation  macro  arguments  are  not  treated  literally 
by  the  system  in  order  to  avoid  the  necessity  of  using 
literal  brackets,  but  there  are  many  examples  where  the 
dynamic  element  is  vital. 


Structure  Representations  for  More  Complicated 
Cases 


The  exact  details  of  how  to  write  structure  representa- 
tions m the  general  case  are  to  be  found  in  the  User’s 
Manual  and  this  paper  will  confine  itself  to  a basic  outline. 
There  are  certain  reserved  words  in  structure  representa- 
tions. Among  these  are:  WITH.  OPT,  OR,  ALL  and  any 
atom  consisting  of  the  letter  "X”  followed  by  an  integer. 
(The  names  of  reserved  words  can  he  changed  dynamically 
by- the  user,  if  lie  desires.)  WITH  is  used  to  specify  de- 
limiters that  consist  of  more  than  one  atom.  For  example, 
if  a delimiter  consists  of  the  atoms  Al,  A 2,  . . .,  Ak,  then 
tills  is  specified  by: 

Al  WITH  A2  WITH  ...  WITH  Ak 

The  remaining  reserved  words  are  used  to  specify 
branches  and  nodes  of  the  delimiter  structure. 

As  has  been  seen,  the  purpose  of  a delimiter  structure  is 
to  specify  a successor  or  set  of  alternative  successors  for 
each  delimiter.  In  a structure  representation  each  specifi- 
catioi.  of  a delimiter  is  immediately  followed  by  a specifica- 
tion of  ns  successor.  This  successor  may  be  defined  in  any 
of  the  following  ways: 

(a)  It"  there  is  a single  possible  successor,  as  in  the  case 
of  the  delimiters  of  the  MOVE  example,  this  is  specified 
simply  by  writing  its  name.  (It  is  convenient  to  imagine  a 
special  symbol  “null"  occurs  at  the  end  of  each  structure 
representation.  Any  delimiter  with  “null"  as  its  successor 
is  a clo-ing  delimiter.) 

(b)  If  there  are  alternative  successors,  this  is  specified 
by  writing: 


OPT  branch  1 OH.  bianch  2 OR  branch  n ALL 

A branch  may  be  a single  delimiter  specification  or  a struc- 
ture in  itself.  An  ex, -11111)10  of  the  use  of  this  facility  is  the 
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following  macro  to  convert  fully  parenthesized  algebraic 
notation  to  Polish  Prefix  notation. 

MCDEF  (OPT  + OR  - OR  • OR  / ALL)  AS  ( :D1.:A1.:A2.  ); 

Here  the  left  parenthesis  is  the  macro  name.  The  replace- 
ment text  consists  of  the  first  delimiter  followed  by  the 
first  argument  followed  by  the  second  argument. 

(c)  If  a delimiter  is  at  the  end  of  a branch,  its  successor 
is  normally  taken  as  the  successor  of  the  occurrence  of  ALL 
corresponding  to  the  branch.  Thus  in  the  above  Polish 
Prefix  example  each  of  the  alternative  arithmetic  opera- 
tors lias  a right  parenthesis  as  its  successor.  However,  a 
delimiter  at  the  end  of  a branch  can  be  given  a different 
successor  hv  writing  the  name  of  a node  at  the  end  of  a 
branch.  A node  is  designated  by  the  letter  “X”  followed 
by  a positive  integer.  The  successor  of  the  delimiter  is  then 
taken  as  the  successor  of  the  node,  which  is  specified  by 
writing  the  name  of  the  node  in  front  of  some  delimiter 
specification  in  the  structure  representation.  The  following 
example  illustrates  the  use  of  nodes.  Assume  a macro 
called  MIX  allows  any  number  of  arguments  separated 
by  commas  and  terminated  by  a semicolon.  It-  structure 
representation  would  be  written:  MIX  Nl  OPT,  Xi  OR;  ALL 

This  is  interpreted  thus.  The  successor  of  MIX  is  either  a 
comma  or  a semicolon.  Xode  XI  is  to  he  associated  with 
these  alternatives  since  XI  has  been  written  before  the 
specification  of  the  alternatives.  If  a comma  is  found  as  a 
delimiter,  its  successors  are  the  successors  of  XI,  namely 
either  a comma  or  a semicolon.  If  a semicolon  is  found,  its 
successor  is  the  successor  of  ALL,  namely  “null." 

Use  of  Macro-Time  Statements 

In  simple  macros  such  as  MOVE,  the  replacement  text 
is  a fixed  skeleton  of  code  which  is  to  replace  each  call. 
This  is  obviously  not  adequate  for  more  sophisticated 
cases.  Consider  the  IF  macro  used  earlier  as  an  example, 
which  had  alternative  forms: 

(a)  IF  argument  1 — argument  2 THEN  argument  3 END 
or  (b)  IF  argument  1 =■  argument  2 THEN  argument  3 ELSE 
argument  4 END 

Clearly  the  replacement  text  of  IF  must  be  made  to  ee-- 
cratc  different  code  in  the  two  eases.  This  can  be  done  by 
using  the  macro-time  GO  TO  statement,  MCGO,  in  us 
form:  MCGO  argument  1 UNLESS  argument  2 «=  argument  3, 

The  definition  of  IF  is  written  as  follows: 

MCDEF  IK  - THEN  OPT  ELSE  END  01t  END  ALL  AS 

< LAC  :Al  /‘Load  first  argument. 

SAD  :A2.  /Skip  if  it  differs  from  the  second 
argument. 

SKP  /Equal  case:  skip  one  instruction 

JMP  XX:T2.  /Unequal  case:  jump  over  inserted 
code. 

:A3.  /Inserted  code 

MCCO  Ll  UNLESS  .1)3.  - ELSE;  /Macro-time  jump  if 

else  clause  is  absent. 

J.VP  YY.-T2.  /Jump  over  else  clause. 
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XX:T2.,  :A4. 

YY  :T2.,  MCGO  L2; 

:L1.XX:T2.,  :L2.  ). 


/Insert  else  clause. 

/Macro-time  jump  to  end  of  replace- 
ment text. 

/Placing  of  macro-time  labels. 


Note  that  the  second  .•'rgument  of  MCGO,  which  is 
“:D3”,  is  evaluated  before  being  compared  with  the 
chaincter  string  “ELSE”.  This  evaluation  causes  the  text 
of  t ie  third  delimiter  to  be  inserted  und  to  take  part  in 
the  comparison.  Note  also  the  use  of  the  initial  value  of  T2 
to  generate  unique  labels.  The  following  two  successive 
calls  of  the  IF  macro: 


IF  A - B THEN  JMS  SUB 
END 

IF  PIG  = DOG  THEN  LAC  3 
DAC  D 

ELSE  LAC  Y 
DAC  Z 

END 


Scope  of  Definitions 

New  constructions  may  be  defined  at  any  time  during 
text  evaluation  but.  ML/I  being  a one-pass  system,  dt-  na- 
tions only  apply  to  text  that  comes  after  them.  It  i-.  pn-sible 
to  redefine  a construction  and  individual  constructions 
may  be  deleted  by  redefining  them  to  have  a null  effect. 
Constructions  may  be  defined  as  local  to  a piece  of  replace- 
ment text  or  even  local  to  the  evaluation  of  an  argument 
It  is  possible  to  use  a macro  to  set  up  the  definition  of 
another  macro,  and  this  is  useful  in  dealing  with  declara- 
tive statements.  Thus  DECLARE  could  be  a macro  >uch 
that  if,  for  example,  the  statement : 

DECLARE  X REAL 

were  encountered,  then  the  DECLARE  macro  would  set 
up  a definition  of  X as  a macro,  which  might,  for  in.-tance, 
take  the  form: 


would  generate  the  code: 

LAC  A /First  call. 

SAD  B 
SKP 

JMP  XXI 
JMS  SUB 

XXI , LAC  PIG  /Se  ond  call . 

SAD  DOG 
SKP 

JMP  XX2 
LAC  C 
DAC  D 
JMP  YY2 

XX2,  LAC  Y 
DAC  Z 

YY2, 

The  two  macro-time  statements  MCSET  (the  macro- 
time assignment  statement)  and  MCGO  can  be  used  to 
form  macro-time  loops,  which  are  useful  in  processing 
macros  with  a variable  number  of  arguments.  The  follow- 
ing macro,  which  is  useful  in  a number  of  applications, 
illustrates  the  macro-time  loop.  The  macro,  which  has  the 
composite  name  “INDEX  (”,  successively  compares  its 
first  argument  with  each  succeeding  argument  until  a 
match  is  found,  and  returns  as  its  value  the  number  of  the 
matching  argument. 

MCDEF  INDEX  WITH  (XI  OPT,  XI  OR)  ALL  AS 

< MCSET  T2  - 2; 

:L2.  MCGO  LI  IF  :AT2.  - : AI . ; 

MCSET  T2  - T2  + 1; 

.MCGO  L2; 

J,l.  :T2.  );  /Insert  value  of  T2. 

This  macro  can  be  used  for  switching.  Assume  it  is 
des;red  to  test  the  second  delimiter  of  a macro  and  branch 
to  macro-time  label  1.2  if  the  delimiter  is  a plus  sign,  to 
L3  if  it  is  a minus  :gn,  and  so  on.  Then  the  following  state- 
ment achieves  this: 

MCGO  L INDEX  (;D2„  +,  ..  /); 


MCDEFG  X AS  ( 100  MCSET  l’l  - G ; >; 

(MCDEFG  is  the  same  as  MCDEF  except  that  the 
definition  is  global  rather  than  local  to  any  containing 
macro.)  This  definition  would  cause  each  subsequent  oc- 
currence of  X to  be  replaced  by  100  and  each  call  of  X 
would,  as  a side-effect,  set  the  permanent  variable  l’l  to 
value  sue.  The  side-effect  could  be  used  to  convey  the 
information  that  X was  of  type  “real". 

Implc  men  t a tiou 

ML/I  has  been  implemented  on  the  PDP-7  and  I.C.T. 
Atlas  2 computers.  It  occupies  about  three  thousand  words 
of  storage.  It  is  planned  to  write  the  logic  of  ML/I  in  a 
macro  language  so  that,  by  suitably  coding  the  basic 
macros  and  running  the  logical  description  through  ML  l 
itself,  it  is  possible  to  generate  code  for  any  machine.  It  is 
hoped  that  this  technique  will  enable  ML/I  to  be  trans- 
ferred to  a new  machine  in  about  otic  man-month,  even 
allowing  for  the  multitude  of  unforeseen  difficulties  this 
kind  of  operation  always  involves. 
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STAGE2  is  the  second  level  of  o bootstrap  sequence  which  is 
easily  implemented  on  any  computer.  It  is  a flexible,  powerful 
macro  processor  designed  specifically  as  a tool  for  constructing 
machine-independent  software.  In  this  paper  the  features  pro- 
vided by  STAGE2  are  summarized,  and  the  implementation 
techniques  which  have  made  it  possible  to  have  STAGE2  run- 
ning on  a new  machine  with  less  than  one  man-week  of  effort 
are  discussed.  The  approach  has  been  successful  on  over  15 
machines  of  widely  varying  characteristics. 

KEY  WORDS  AND  PHRASES,  booh  trapping,  macro  processing,  machine 
independence,  programming  languages,  implementation  techniques 
C*  CATEGORIES:  4.12,  4.22 


1.  Introduction 

In  an  earlier  paper  [1]  R.  J.  Orgass  and  I presented  a 
trivial  macro  processor  called  -SIMCMP,  which  we  pro- 
posed as  a base  for  implementing  a mobile  programming 
system.  The  design  criterion  for  SIMCMP  was  simplicity 
of  implementation,  and  it  was  severely  limited  in  the 
source  code  which  it  could  accept.  Its  sole  function  was  to 
translate  a more  complex  processor.  This  paper  describes 
STAGE2,  the  second  level  of  the  bootstrap. 

STACK-’  is  a flexible,  powerful  macro  processor  written 
in  a language  which  can  be  translated  by  SIMCMP. 
It  is  designed  specifically  for  the  task  of  implementing 
machine-independent  software,  although  it  can  also  serve 
other  purposes.  Some  features  normally  associated  with  a 
generalized  macro  processor  have  been  omitted  (for 
example,  all  macro  definitions  must  be  presented  before 
any  source  code  is  read).  These  omissions  are  required 
because  of  restrictions  imposed  by  SIMCMP  on  the 
number  of  program  labels.  They  do  not  affect  the  primary 
ft  notion  of  STAGES,  and  hence  I feel  that  they  do  not 
represent  di-ign  flaws. 

To  be  effective  as  a tool  for  creating  machine-inde- 
pendent software,  STAGES  itself  must  be  highly  mobile. 
For  this  rea-on,  the  support  which  the  system  requires 
from  existing  software  on  the  target  computer  should  be 
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minimal.  A generalized  I/O  package  [2]  provides  the  I/O 
interface  for  both  SIMCMP  and  STAGE2.  It  assumes  that 
the  following  operations  on  sequential  files  arc  provided 
by  the  operating  system  available  on  the  target  machine: 

(1)  read  one  line, 

(2)  detect  end-of-file, 

(3)  write  one  line, 

(4)  write  end-of-file, 

(5)  rewind. 

These  operations  need  only  be  available  on  those  devices 
for  which  they  are  meaningful.  The  generalized  I/O 
package  carries  flags  which  specif}'  the  legal  operation  on 
each  device  and  will  intercept  any  illegal  requests. 

In  a minimal  configuration,  only  three  devices  arc  re- 
quired by  STAGE2.  Conceptually,  they  arc  a “card 
reader,"  "card  punch,”  and  “printer,”  but  they  may  be 
implemented  by  any  physical  devices.  It  must  be  possible 
to  perform  operations  (1)  and  (2)  on  the  "card  reader,” 
and  operation  (3)  on  the  “card  punch”  and  '‘printer.” 
Operation  (4)  can  be  used  to  clear  the  last  buffer  if  the 
output  is  blocked.  As  described  in  Section  2,  STAGE2  can 
use  secondary'  storage  (tape  or  disk)  to  advantage.  A total 
of  nine  files,  including  the  three  just  mentioned,  would  be 
the  maximum.  The  six  additional  files  can  be  used  as 
secondary  storage  devices,  additional  inputs,  or  additional 
outputs.  Generally  all  five  operations  would  be  possible  on 
each,  although  this  is  not  strictly  necessary. 

Implementation  of  STAGE2  on  a new  computer  re- 
quires less  than  one  man-week  of  effort.  An  existing  version 
is  unnecessary;  the  bootstrap  process  is  carried  out  from  a 
source  deck,  tape,  or  listing.  The  system  has  been  tested 
in  over  15  implementations,  several  completed  by  in- 
experienced personnel.  The  basic  design  philosophy  of  the 
system  [3,  4]  indicates  a possible  solution  to  the  "software 
crisis”  which  is  plaguing  the  computer  industry  today. 

The  remainder  of  this  paper  gives  a brief  overview  of 
the  facilities  provided  by  STAGE2,  and  the  programmir  - 
techniques  used  in  its  construction.  A comprehensive 
user’s  manual  [5]  is  available  for  those  interested  in  furthe. 
details. 

2.  User's  View- 

In  many  ways,  STAGE2  is  similar  to  Limp  [6].  It  em- 
ploys a scanning  mechanism  to  recognize  macro  calls  and 
isolate  parameter  strings,  and  the  ability  to  perform 
different  parameter  conversions  has  been  retained  and 
extended,  The  code  body  docs  not  include  the  “grouping” 
concept,  nor  Limp’s  Snobol  interpreter.  Free  use  of  I/O 
devices  is  permitted. 

Each  macro  definition  has  two  parts:  a template  and  a 
code  body.  The  template  is  used  as  a pattern  for  recogni- 
tion of  macro  calls,  and  the  code  body  directs  the  expan- 
sion of  the  macro.  Roth  the  template  and  the  code  body 
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,1>t  >| ii *rial  characters  winch  aiv  specified  on  the  first  line 
„f  lie  lielinitions  (the  Jkij  hue).  Table  I summarizes  these 
characters. 

Template  matching  is  carried  ont  by  a scanner  which 
compares  the  input  line  with  the  templates.  Characters  in 
(lie  template  which  are  not  parameter  flags  (Table  I) 
must  match  the  corresponding  characters  of  the  input 
line  exactly.  A parameter  flag  will  match  any  substring  of 
the  input  line  which  is  balanced  with  respect  to  the  paren- 
theses specified  bv  the  flag  line  (a  null  string  is  considered 
to  be  balanced).  By  requiring  that  a parameter  flag  match 
a balanced  substring  of  the  input  line,  STAGE'-’  allows 
grouping  by  parentheses.  This  is  a useful  feature  when 
structures  such  as  arithmetic  expressions  or  lists  of  oper- 
ands are  being  analyzed. 


ALPHA  - (BETA  + GAMMA)  « DELTA 
(a)  A typical  input  line 

ALPHA  - (')  • DELTA 
ALPHA  - ’ • ' 

ALPHA  - ' 

» ^ » 

(b)  Several  templaies  which  could  match  the  input  line 
given  in  Figure  1(a) 

Fig.  1.  Template  matching 


Figures  1(a)  and  1(b)  show  an  input  line  and  several 
templates  which  would  match  it.  The  flag  characters  are 
those  of  Table  I.  Ambiguity  in  the  template  match  is  re- 
solved by  five  rules  (see  Appendix).  Together  they  have 
the  effect  of  maximizing  the  number  of  literal  characters 
matched.  In  Figure  1,  for  example,  the  rules  force  the 
input  line  to  match  the  first  template. 

The  actual  parameters  of  a macro  call  are  the  substrings 
which  match  the  parameter  flags  of  the  template.  Within 
the  code  body,  these  actual  parameters  are  referred  to  by 
number:  the  string  matched  to  the  leftmost  flag  is  param- 
eter 1,  the  one  matched  to  the  next  flag  is  parameter  2, 
and  so  forth.  A maximum  of  nine  flags  is  allowed  in  a 
single  template.  The  first  template  of  Figure  1(b)  has  a 
single  parameter  flag.  If  the  input  line  of  Figure  1(a)  were 
matched  to  this  template,  actual  parameter  1 would  be 
BETA  -f  GAMMA.  Actual  parameters  2-9  would  not  be 
defined  by  the  template  match. 

Associated  with  each  template  is  a code  body  which 
specifics  the  text  to  be  constructed  by  the  macro.  Each 
line  of  the  code  body  is  used  to  construct  a line  which  is 
then  either  output  (by  means  of  a processor  function,  sec 


TABLE  I CiiAitACTi.ii-.  Deuxed  iiv  the  Flag  Line 


Ch>ir<ut<r 

Petition 

Meaning 

Ckarai.er 

1 

End  of  source  language  line 

o 

Parameter  flag  for  template 

3 

Kml  of  target  language  line 

$ 

4 

Escape  character  for  target  language 

t 

5 

Zero 

0 

6 

Filler  for  fixed  fields  in  the  target 

."pace 

language 

7 

Left  parenthesis 

( 

8 

Addition  operator 

- 

0 

Subtraction  operator 

- 

10 

Multiplication  operator 

• 

11 

Division  operator 

, 

13 

Right  parenthesis 

) 

(3)  below)  or  else  is  resubmitted  to  the  scanner  for  recog- 
nition. To  construct  the  line,  characters  are  copied  from 
the  code  body  line  until  the  end-of-line  (Table  I)  is  recog- 
nized. The  line  is  then  terminated  and  passed  to  the 
scanner.  If  an  escape  character  (Table  I)  is  recognized 
during  this  process,  it  is  not  copied,  and  the  next  character 
of  the  line  is  examined  to  determine  what  action  should  be 
taken.  There  are  three  possibilities: 

(1)  If  the  next  character  is  an  escape  or  an  end-of  line, 
then  it  is  copied  into  the  line  being  constructed. 

(2)  If  the  next  character  is  a digit,  then  some  trans- 
formation of  the  corresponding  actual  parameter  is  copied 
into  the  line  being  constructed.  The  particular  transforma- 
tion applied  is  determined  by  the  character  following  the 
digit  (see  Table  II).  A transformation  applied  to  parameter 
0 is  interpreted  as  a request  for  an  arbitrary  symbol  which 
is  unique  within  the  current  macro.  Up  to  ten  such  symbols 
can  be  generated  in  any  one  macro.  The  second  character 
following  the  escape  specifies  which  symbol  should  be 
copied  into  the  line  being  constructed. 

(3)  If  the  next  character  is  F,  then  a special  processor 
function  is  executed.  The  particular  function  is  determined 
by  the  character  follow  ing  the  F (see  Table  III). 

STAGE2  provides  three  levels  of  storage:  parameters, 
an  associative  memory,  and  up  to  six  I/O  files.  The 
parameters  can  be  used  for  working  storage  within  a 
single  macro.  Information  can  be  made  accessible  to  all 
macros  via  the  associative  memory.  Intermediate  text 
can  be  written  on  any  of  the  I/O  files  and  later  recovered. 

Each  macro  rail  has  storage  space  for  nine  parameters 
associated  with  it.  The  template  match  may  establish 
initial  values  for  some  of  these  parameters.  Parameter 
values  may  also  be  established  by  the  code  body,  using 
transformation  f>  (see  Tabic  II).  The  scope  of  the  param- 
eters is  the  code  body  of  the  macro  in  which  they  were 
established.  They  are  not  accessible  to  macros  called  by 
the  code  body.  Their  values  are,  however,  preserved  during 
such  rails.  On  completion  of  a call,  all  parameters  as- 
sociated with  that  call  disappear. 
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TAUI.I'.  11  l*ARAM».rt.ll  CoXYKUSION  DIGITS 


i'omtrnom 

Ihtil 


A f lion 


o 

1,  2 

3 

4 

5 

6 

7 

8 


F UttfltOm 

/)l|ll 

0 

1 

•) 

3 

4 

5 
G 

7 

8 
V 

E 


Cnpv  t lie  parameter  to  the  constructed  line 
Copy  n st  ring  from  memory  to  the  constructed  line 
Copy  the  break  character  to  the  constructed  line 
Copy  the  value  of  a parameter,  treated  as  an  arith- 
metic expression,  into  the  constructed  line 
Copy  a parameter  length  to  the  constructed  line 
lfeset  the  value  of  a parameter 
Initiate  a context-controlled  iteration 
Copy  an  integer  equivalent  to  a single  character  into 
the  constructed  line 

TAB1.K  111.  Processor  Function  Digits 

Action 


Terminate  processing 

Output  a line  without  rescanning 

Change  I/O  channels  and  copy  text. 

Store  information  into  memory 
Set  skip  counter  unconditionally 
Set  skip  counter  conditionally  on  string  equality 
Set  skip  counter  conditionally  on  the  relative  values  of 
two  expressions 

Initiate  a couut-conti  ulled  iteration 
Advance  an  iteration 
Escape  from  the  current  macro 
Generate  error  traceback 


The  associative  memory  is  addressed  by  character 
strings,  and  its  contents  ure  also  character  strings.  N'o 
restriction  is  placed  on  the  format  of  either  addresses  or 
contents.  Information  is  entered  into  memory  by  a proces- 
sor function,  and  accessed  by  parameter  transformations. 
Because  it  is  global  to  all  macro  calls,  the  memory  can  be 
used  to  pass  information  between  macros.  Typical  uses  of 
the  memory  are  to  hold  a symbol  table,  a pushdown  stack 
for  translating  expressions,  and  information  about  the 
current  contents  of  various  registers  for  use  in  ‘'peephole” 
optimization  [7). 

A maximum  of  nine  I/O  files  can  be  made  accessible  to 
STAGE-’.  At  least  three  (the  ‘reader,”  “punch,”  and 
“printer”)  will  always  be  available.  By  suitable  processor 
functions,  the  user  can  direct  output  generated  by 
STAGE2  to  any  file  on  which  writing  is  allowed.  The  input 
may  be  switched  to  any  file  on  which  reading  is  allowed. 
Any  file  may  be  rewound  if  rewinding  is  allowed  by  its 
implementation. 

The  main  u-c  of  I,  O files  is  to  permit  multipass  opera- 
tion. For  example,  complex  code  optimization,  such  as 
register  allocation  |s,  9],  can  be  performed  using  the 
available  I <>  files  for  tcm|N>rary  storage  of  intermediate 
text  Information  about  register  contents  can  be  accumu- 
lated in  the  memory  lictwecn  labels,  while  intermediate 


text  is  written  on  one  or  more  files.  At  the  next  label,  this 
information  is  examined  and  a register  assignment  made. 
The  intermediate  text  is  then  read  back  and  the  final 
code  is  generated. 

STAGE2  can  evaluate  integer  arithmetic  expressions 
involving  addition,  subtraction,  multiplication,  and  divi- 
sion. Parentheses  may  be  used  to  any  depth  (subject  to 
storage  availability).  The  operands  may  be  either  explicit 
integers  or  symbols.  A symbol  is  looked  up  in  the  associa 
tive  memory,  where  it  must  have  an  integer  value. 

Conditional  operations  arc  available  for  testing  the 
equality  of  two  strings  and  the  relative  magnitude  of  two 
expressions.  If  the  condition  is  satisfied,  an  expression  is 
evaluated  to  determine  how  many  lines  should  be  skipped. 
A skip  is  not  restricted  to  the  macro  in  which  the  condi 
tioual  operation  appeared. 

It  is  possible  to  loop  within  a rode  body.  Thy  loop  is 
controlled  either  by  a counter  or  by  a string  am.  a set  of 
delimiters.  Using  the  latter,  known  as  context  -ont  roller  I 
iteration,  it  is  possible  to  analyze  complex  parameters 
such  as  lists  of  operands  and  arithmetic  expressions.  The 
context  controlled  iteration  is,  in  effect,  a token  breakout 
routine  similar  to  that  found  in  a compiler.  No  particular 
delimiters  are  assumed;  they  are  provided  when  the  itera- 
tion is  initiated. 

Tables  II  and  III  summarize  the  parameter  trans- 
formations and  special  processor  functions  available  to 
the  user  of  STAGE2.  The  brief  discussion  presented  in 
this  section  is  intended  to  emphasize  tin*  main  features  of 
the  processor  and  sketch  the  broad  outlines  of  its  opera 
tion.  For  full  details,  the  interested  reader  is  reierred  to 
the  user’s  manual  [3], 

3.  Implementation 

The  programming  techniques  used  in  writing  STAGE‘2 
were  chosen  to  make  it  easy  to  implement  on  virtually  any 
machine.  It  is  coded  in  the  assembly  language  of  a special 
purpose  computer,  called  Fi.rn,  which  was  designed  to 
bundle  the  data  structures  relevant  to  macro  processing: 
trees,  strings,  and  integers.  Fi.un  dors  not  exist;  it  >-  n 
abstract  machine  [3]  conceived  solely  for  the  purpose  >r 
coding  STAGE2.  (A  complete  description  of  Fi.l'h, 
giving  details  of  the  rationale  behind  the  design,  can  be 
found  in  [10].)  To  implement  STAGK2  on  a real  computer, 
the  Flvb  operations  arc  realized  as  macros  which  can  be 
expanded  by  S1MCMP  [1].  Flvb  has  2S  machine  opera- 
tions and  2 pseudo  operations,  so  that  a total  of  30  macros 
must  be  written. 

The  general  organization  of  the  Flvb  computer  is 
shown  in'  Figure  2.  Each  register  is  made  tip  of  three  fields, 
as  described  in  Table  IV.  The  instruction  set  is  given  in 
Table  V.  Note  that  many  instructions  which  are  common- 
place on  computers  today  are  not  included.  Shift  instruc- 
tions and  Boolean  operations,  for  example,  are  conspicuous 
by  their  absence,  the  reason  being  that  STAGK2  does  not 
require  such  operations.  It  is  important  to  keep  the  purpose 
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Fig.  2.  Organization  of  tlie  Fu  » computer 


of  this  abstract  machine  firmly  in  mind  when  criticizing 
omissions  in  the  instruction  set.  Flub  makes  no  pretense 
about  being  computer  for  general  problems;  it  is  specifi- 
cally tailored  to  run  STAGE2. 

All  Flub  operands  are  register  names,  except  target 
locations  for  jump  instructions  and  the  first  operand  of 
MESSAGE  " TO  Each  of  these  consists  of  two  digits. 
(GET  and  STO  each  specify  a register  which  contains 
tlie  desired  memory  address.)  Each  apostrophe  in  Table  V 
thus  represents  a single  letter  or  digit.  This  conforms  to 
the  restriction  on  parameters  which  is  imposed  by 
SIMC'MP,  and  in  fact  the  lines  listed  in  Table  V are 
exactly  the  templates  for  the  SIMC.MP  macros  used  to 
translate  STAGE2. 

An  advantage  of  performing  all  Flub  operations  on 
registers  is  that  it  is  possible  to  make  a realization  of 
STAGE2  more  efficient  by  using  different  storage  tech- 
niques for  registers  and  memory.  On  one  computer,  the 
Titan  at  Cambridge,  it  was  possible  to  assign  flip-flop 
registers  to  all  of  the  Flub  registers.  Even  if  the  Flub 
registers  are  stored  in  core,  their  fields  can  be  left  unpacked 
lor  rapid  access.  The  fields  of  the  memory  words  would 
be  packed  to  conserve  space. 

All  Flub  I O is  handled  through  a generalized  I/O  inter- 
face (2)  which  provides  access  to  a number  of  channels 
via  a line  buffer.  Information  is  transmitted  one  character 
at  a time  between  the  line  buffer  and  the  general  registers. 
Full  lines  are  transmitted  between  the  line  buffer  and  the 
channels.  This  view  of  I/O  is  quite  similar  to  that  proposed 
for  Algol  tiO  [II,  12]  and  being  implemented  for  Algol 
OS  [13]. 

The  rode  bodies  of  the  macros  whose  templates  are 
shown  in  Table  V,  the  I/O  interface,  and  SIMCMP  are 
machine-dependent.  They  must  be  hand-coded  for  each 
implementation,  a task  which  requires  about  S man-hours. 
Wc  have  a set  of  macros  whose  code  bodies  arc  written 


TABLE  IV. 

Breakdown  of  the  Fi.un  Word 

Field 

Minimum 
Range  oj  Valuet 

Pur  post 

FI-G 

0,  3 

Indicator  bits 

VAL 

0,  To  hold  a single  character  or  the  length 

ma\(C,L)  -f  1 of  a string.  C is  the  largest  integer 
which  represents  a character,  L is 
the  maximum  string  length 

PTR 

-A,  A 

To  address  Fu  n memory,  and  act  as  a 
general  integer  accumulator.  A is  the 
largest  address  of  the  targ<  t ma- 
chine's memory 

TABLE  V. 

Flvu  Machine  Instructions 

/.  Data  Transfer  Operations 


(a)  Register  to  Register 

(b)  Register  to  Memory 

KLG  ' - '. 

GET  1 = '. 

VAL  ' - PTR  '. 
PTR  ' = VAL  \ 

STO  1 = 

2.  Integer  Arithmetic  Operations 

(a)  VAL  field  arithmetic 

(b)  PTR  Field  arithmetic 

VAL  ' = ' + 

PTR  ' = ' + 

VAL 

PTR  ' = 

PTR  ' = 

PTR  ' = ' / '. 

S.  Input/Output  Operations 

(a)  Character  I/O 

(b)  Line  I/O 

VAL  ' = CHAR. 

READ  NEXT  '. 

CHAR  = VAL  '. 

WRITE  NEXT  '. 
REWIND  '. 
MESSAGE  " TO  '. 

/.  Control  Operations 

(a)  Unconditional 

(b)  Conditional 

STOP. 

TO  " IF  FLG  ' - ' 

TO 

TO  "IF  FLG  ' NE 

TO  " BY  '. 

TO  " IF  VAL  ' =•  ' 

RETURN  BY  '. 

TO  " IF  VAL  ' NE 
TO  " IF  PTR  ' - ' 
TO  " IF  PTR  ' NE 
TO  "IF  PTR  ' GE 

in  ASA  Fortran,  and  an  ASA  Fortran  version  of  the 
I/O  package.  SIMC.MP  is  also  described  in  ASA  Fortran 
[1].  Thus,  if  Fortran  is  available  on  the  target  computer, 
initial  implementation  of  STAGE2  is  trivial. 

The  initial  implementation  of  STAGE2  is  via  SIMC.MP. 
Because  of  the  inherent  weakness  of  SIMC.MP,  this 
implementation  will  generally  not  be  extremely  efficient. 
To  improve  the  efficiency,  one  would  rewrite  the  30  macros 
to  take  advantage  of  the  powerful  facilities  which  STAGE2 
provides  for  optimization.  Then,  using  these  macros  and 
the  initial  implementation  of  STAGE2,  it  is  possible  to 
retranslate  STAGE2. 

Still  further  improvements  in  efficiency  can  be  obtained 
by  hand-coding  certain  critical  routines.  When  STAGF.2  is 
translated  by  cither  SIMC.MP  or  STAGE2,  the  result 
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is  an  assembly  code  program.  It  is  possible  to  make  meas- 
urements on  tlio  performance  of  this  program  to  determine 
where  it  is  spending  most  of  its  time.  The  critical  routines 
ran  then  be  recoded,  taking  advantage  of  all  available 
programming  tricks.  The  effort  involved  in  this  recoding 
i~>  miniscule  compared  with  that  involved  in  hand-coding 
the  entire  processor. 

4.  Conclusions 

Tin  purpose  of  STAGE2  is  to  provide  a tool  for  con- 
structing machine-independent  software.  STAGE2  itself 
i*  machine-independent,  and  was  designed  in  such  a way 
that  it  could  be  moved  to  a new  machine  with  virtually 
' no  effort  and  without  relying  on  existing  software.  I believe 
that  these  objectives  have  been  met.  As  noted  in  thelntro- 
duction,  the  mobility  of  STAG  It'-  has  been  proved  in  over 
15  implementations.  In  fact,  in  some  cases  we  have  found 


TABLE  VI  Implementation  for  CDC  0000  Series 

/.  Environment 

Generalized  I/O  package 

495  words 

I/O  butlers 

3010 

System  routine 

1622 

Pat  a space 

12000 

Total:  17136  words 
II  STAGEi 

Flub  source  code 

977  statements 

Unoptimized  version 

2373  words 

Optimized  version 

1667  words 

III.  Manning  time  to  translate  STAGEi  (6+00) 

Uziopf imucd  version 

42  25-1  seconds  CP 
7.781  seconds  PP 

Optimized  version 

36.360  seconds  CP 
7 . 233  seconds  PP 

that  leimplementation  from  scratch  was  simpler  than 
try  ing  to  bring  tip  an  existing  version  for  the  same  machine 
from  a different  installation! 

One  of  the  major  questions  which  arises  with  a machine- 
independent  implementation  such  as  that  described  in  this 
paper  is  how  much  it  costs.  IV hat  penalty  is  assessed  in 
terms  of  reduced  efficiency  in  both  time  and  space?  Un- 
fortunately, I cannot  answer  that  question  conclusively. 
'Jo  do  so  would  require  an  implementation  of  STAGES 
“by  hand”  for  comparison  purposes.  An  an  indication, 
however,  consider  the  statistics  of  Table  VI. 

These  numbers  were  obtained  from  STAGE2,  version 
2,  as  implemented  on  the  CDC  0100  at  the  University  of 
Colorado.  At  l!  < time  the  runs  were  made,  we  were  operat- 
ing mu  let  the  standard  release  of  Scorn  3.1.0.  The  general- 
ized I t>  package  wan  tailored  to  Scorn  and  the  (>100,  and 
the  system  routines  were  nnmodilicd.  I/O  butters  were 


provided  for  nine  channels,  using  the  minimum  number  of 
words  to  allow  double  buffering  with  i he  device  type 
assigned  to  the  channel  (129  words  for  disk  files,  1025 
words  for  tape  tiles).  Note  that  with  this  environment, 
STAGE2  itself  represents  less  than  13  percent  of  the  total 
core  requirement. 

In  the  unoptimized  version,  each  Flub  instruction  was 
translated  to  Compass  in  the  most  straightforward  way. 
No  attempt  was  made  to  take  advantage  of  special 
operands  or  to  minimize  instruction  length  by  retaining 
frequently  used  constants  in  registers,  l'or  example,  the 
Flub  statement 

PTR  A = 0 -t  0 

was  translated  into  a fetch  of  the  PTR  field  of  register  0, 
fetch  and  add  of  the  same  field,  and  finally  a store  into 
the  PTR  field  of  A.  The  optimizing  macros  took  advantage 
of  such  operands.  In  the  case  noted  above,  a zero  was 
stored  in  PTR  A (the  Flub  register  0 contain  0 in  all  of 
its  fields).  They  provide  l'or  certain  frequently  used 
constants  (such  as  0 and  1)  to  bo  held  in  registers  at  all 
times,  and  recognize  other  machine-dependent  situations 
where  15-bit  instructions  can  be  used  instead  of  50-bit 
instructions.  No  global  optimization  is  performed;  only 
information  derived  from  a single  macro  call  is  examined. 

Note  that  although  the  optimization  provided  a signifi- 
cant 30  percent  reduction  in  the  size  of  STAGE'-’,  the 
total  length  of  the  optimized  version  was  still  97  percent  of 
that  of  the  unoptimized  version.  Optimization  also  pro- 
vided somewhat  faster  code — the  optimized  version  re- 
quired only  about  SO  percent  of  the  time  used  by  the 
unoptimized  version.  Both  programs  were  given  the  same 
task:  translating  STAGE2  to  Compass  Using  the  optimiz- 
ing macros.  Since  the  Fi.vu  source  code  for  ST.VGE2  is 
977  statements  long,  STAGE2  translates  at  roughly  1000 
cards  per  minute  with  these  macros. 

To  date,  STAGE2  has  boon  used  to  translate  a compre- 
hensive text  processor  known  as  Mitem  [14],  and  a small, 
interactive  editor  called  Mice.  Both  of  these  programs 
have  been  implemented  on  several  computers  with  loss 
than  one  man-week  of  effort.  We  arc  currently  writing  a 
page  layout  and  printing  program  similar  to  Text  300 
[IS]  and  Format  [10],  and  an  interactive  Basic  [17]  system. 

I believe  that  the  techniques  used  in  implementing 
STAGE2,  and  STAGE2  itself,  can  help  to  alleviate  the 
software  crisis  in  which  we  find  ourselves  today.  By  now, 
most  people  have  learned  the  value  of  higher  level  lan- 
guages for  machine  independence.  The  difficult  areas  are 
those  in  which  no  high  level  language  is  quite  suited  to  the 
problem.  There  are  two  possible  taeks  to  take:  (1)  twist 
the  problem  to  fit  some  existing  language:  (2)  design 
another  language.  The  major  objection  to  (2)  has  been  the 
difficulty  of  implementing  a new  language,  and  the 
realization  that  the  processor  will  be  useless  on  any  other 
machine.  STAGE2  removes  the  latter  construct.  \ 
processor  is  still  difficult  to  construct,  but  once  done  it 
can  bo  used  almost  anywhere. 
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Appcndiv.  Template  Matching 

The  templates  are  organized  into  a tree,  with  each  pat- 
tern element  (single  character  or  parameter  Hat;;  cor- 
rcs|H>mling  to  a brunch.  An  example  of  a template  tree  is 
shown  in  Figures  3(a)  and  3(b).  Uppercase  letters  and 
special  characters  denote  themselves.  (A  space  appears 
as  no  character  at  *11.)  A lowercase  c denotes- the  end-of- 
line  marker,  and  a lowercase  p the  parameter  flag.  The 
reason  for  using  c and  p is  that  these  branches  are  not 
n irmal  characters.  As  the  templates  arc  being  read  in, 
eich  end-of-line  flag  (or  carriage  return,  if  the  cnd-of-line 
Hag  is  absent)  is  replaced  by  a special  marker.  Each  param- 
e.er  flag  is  likewise  replaced  by  a marker  of  another  type. 
If  an  input  line  has  no  end-of-line  Hag,  then  the  carriage 
return  is  replaced  by  the  c marker.  Thus  there  is  no  internal 
distinction  between  an  end  of-iine  flag  and  a carriage 
return. 

Dashed  lines  in  Figure  3(b)  represent  nodes  of  the  tree. 
Each  branch  (character)  has  a direction  associated  with 
it --left  to  right  in  Figure  3(b).  A given  node  may  have  any 
number  of  branches  directed  away  from  it,  but  not  more 
than  one  directed  toward  it.  One  node,  known  as  the  root, 
has  no  branches  directed  toward  it.  Several  other  nodes 
have  no  branches  directed  away  from  them.  These  are  the 
lemes  of  the  tree,  and  are  numbered  to  correspond  with 
the  templates.  When  an  input  line  matches  the  tree  from 
the  root  to  some  leaf,  it  is  recognized  as  an  instance  of  the 
template  corresponding  to  that  leaf. 

In  Figure  3(b),  the  branches  leaving  a node  are  ar- 
ranged vertically.  Thus  the  root  has  two  branches  leaving 
it,  an  S and  a parameter  flag.  The  node  toward  which  S 
is  directed  has  only  one  branch  leaving  it — the  character 
A.  We  say  that  one  node  can  be  reached  from  another  by  a 
branch  if  the  branch  is  directed  from  the  first  node  to  the 
second.  Hence  the  nolle  between  S and  A can  be  reached 
from  the  root  by  S. 


(1)  SAM  - A. 

(2)  SAM  - '. 

(3)  ' - '. 

(4)  ’ - A. 

(5)  ' - ' - 

(«)  SAM  = JOE. 

Kio.  3(a).  A set  of  templates 


It.K.t  8 — A — M - — -r- A — c — (t) 

. p ...  c _ (2) 

. J ...  O -.  E - c - (0) 
• P |—  e — (3) 

— - p — c — (5) 

- A — e — (t) 

Fin.  3(li).  Tlie  tree  built  from  the  templates  of  Figure  3(a) 
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When  an  input  line  is  read,  the  end-of-line  Hag  is  re- 
placed by  a termination  element.  If  there  is  no  end  of- 
line  flag,  then  the  carriage  return  is  replaced.  Parameter 
flag  characters  are  not  recognized  when  input  lines  are 
being  read;  they  are  only  significant  in  definitions.  The 
input  line  is  matched  against  the  template  tree  according 
to  the  following  rules. 

Rule  1 . Rule  2 is  applied  to  the  root  of  the  tree  and  the 
first  character  of  the  input  line. 

Rule  2.  If  one  of  the  branches  leaving  the  current  nolle 
of  the  tree  is  identical  to  the  current  input  character, 
then  that  branch  matches  the  current  input  character. 
Otherwise.  Rule  3 is  applied  to  the  current  node  and  input 
character.  If  the  branch  matched  is  an  end-of-line  marker, 
the  input  line  is  recognized.  Otherwise  Rule  2 is  applied  to 
the  node  reached  from  the  current  node  by  that  branch 
and  the  next  character  of  the  input  line. 

Rule  3.  If  one  of  the  branches  leaving  the  current  node 
of  the  tree  is  a parameter  flag,  then  Rule  2 is  applied  to 
the  node  reached  from  the  current  node  by  that  branch, 
and  the  current  input  character.  The  branch  matches  a 
null  string.  Otherwise,  Rule  4 is  applied  to  the  current 
node. 

Rule  -i.  If  the  current  node  is  the  root,  the  match  fails. 
Otherwise,  if  the  branch  entering  the  current  node  is  not  a 
parameter  flag,  then  Rule  3 is  applied  to  the  previc us  node 
and  the  input  character  which  matched  the  entering 
branch.  Otherwise  Rule  5 is  applied  to  the  current  node 
and  current  input  character. 

Rule  5.  The  substring  matched  by  the  branch  enter- 
ing the  current  node  is  lengthened  by  appending  the 
shortest  balanced  substring  of  the  input  line  which  begins 
at  the  current  input  character.  Rule  2 is  then  applied  to 
the  current  node  and  the  input  character  following  the 
new  substring.  If  no  such  substring  can  be  found,  Rule  4 
is  applied  to  the  previous  node  and  the  first  input  character 
matched  by  the  parameter  flag.  If  the  parameter  flag 
matched  the  mill  string,  the  current  input  character  is  used. 

If  the  match  fails,  the  input  line  is  written  out.  Other- 
wise the  substring  which  matched  the  leftmost  parameter 
flag  is  made  parameter  1,  the  substring  which  matched  the 
next  parameter  flag  becomes  parameter  2,  and  so  forth. 
(A  maximum  of  nine  parameter  flags  is  allowed  in  one 
template.)  When  the  parameters  have  been  set,  interpreta- 
tion of  the  code  body  begins. 

As  an  example  of  the  matching  process,  consider  the  set 
of  templates  of  Figure  3(a)  and  the  corresponding  tree  of 
Figure  3(b).  The  input  line  SAM  = A will  obviously 
match  template  1.  It  could  also  match  template  2,  with  A 
the  value  of  parameter  1,  template  3 with  SAM  and  A as 
parameters,  or  template  4 with  SAM  matching  the 
parameter  flag.  Let  us  see  how  the  rules  operate  to  deter- 
mine which  of  these  possibilities  will  actually  iccur.  Rule 
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1 gets  the  whole  process  >t..rtni  b\  calling  fur  application 
of  Rule  2 tu  the  root  ami  the  lir>t  character  of  the  input 
stiing.  The  fir-t  cluiractur  of  the  input  string  is  S,  aiul 
there  is  an  S hraiich  directed  away  from  the  root  of  the 
tree.  Thus  Rule  2 matches  S to  this  branch.  The  branch 
matched  is  not  an  end-of-lnie  marker.  Hence  Rule  2 is 
applied  to  the  node  reached  by  that  branch,  and  the  next 
character  of  the  input  string.  In  onr  case  the  next  input 
character  happens  to  be  A,  and  there  is  an  A branch 
directed  away  from  the  node  reached  by  S from  the  root. 
Since  this  branch  is  not  an  end-of-Jine  marker,  Rule  2 
is  applied  again.  The  process  continues,  with  Rule  2 
finding  a match  at  each  node.  Finally,  it  matches  the 
terminating  element  of  the  line  to  the  c branch,  and  recog- 
nizes an  instance  of  template  1. 

At  first  glance,  one  might  assume  that  the  input  line  B = 
C = A would  match  template  -1  with  B = C as  the  value 
of  the  actual  parameter.  This  is  not  true,  however,  as  an 
analysis  of  the  scan  w ill  show.  Rule  1 starts  us  off  as  above, 
but  this  time  Rule  2 does  not  produce  a match  and  we  must 
apply  Rule  3.  There  is  a parameter  marker.  Rule  2 is 
applied  to  tiie  node  reached  by  this  branch  and  the  cur- 
rent input  character  (B).  Rule  2 fails  to  produce  a match 
here  also,  so  Rule  3 is  tried.  Unfortunately,  there  is  no 
parameter  marker  leaving  this  node,  so  that  Rule  3 sends 
us  on  to  Rule  -1.  The  current  node  is  not  the  root  but  the 
branch  entering  the  current  node  is  a parameter  flag. 
Ri  le  .')  is  therefore  used  to  extend  the  null  string  which 
originally  matched  this  (lag.  B is  a balanced  substring,  so 
that  we  now  apply  Rule  2 to  the  current  node  and  the 
space  character  which  follows  B.  This  time  Rule  2 pro- 
duces a match,  and  we  can  proceed.  The  = and  the  second 
space  are  also  matched  by  Rule  2,  but  then  Rule  2 cannot 
find  a match  for  C.  Thus  Rule  3 is  used  to  advance  along 
tiie  parameter  branch,  matching  the  parameter  to  the 
null  string.  We  will  now  have  the  same  situation  which 
occurred  at  tiie  first  parameter  marker— Rules  2 and  3 will 
be  unable  to  cope  with  the  following  node,  and  eventually 
Rule  A will  be  called  upon  to  extend  the  substring  matched 
by  tiie  parameter  flag.  Rule  2 will  then  find  a match  for 
the  space  following  the  C,  and  the  whole  process  will 
repeat  itself.  The  A will  finally  be  matched  to  the  last 
parameter  flan,  and  the  matching  of  the  terminator  will 
complete  the  process.  The  line  will  thus  be  recognized  as 
an  instance  of  template  o rather  than  template  4. 

I.et  us  now  consider  the  input  line  (B  - C)  = A.  This 
is  the  same  a<  that  of  the  previous  example,  except  that 
parentheses  have  been  added  to  group  the  characters  B = 
C together.  The  scan  of  this  line  will  begin  in  exactly  the 
same  way  as  the  scan  of  B = 0 = A.  This  time,  however, 
when  Rule  is  applied  to  extend  the  substring  of  the 
input  which  begins  at  the  first  input  character  is  (B  = C). 
We  now  appl>  Rule  2 to  the  node  following  the  parameter 
marker  and  a space  character  from  the  input  string.  There 
is  a match,  so  Rule  2 is  applied  to  the  next  node  and  the  = 
character.  Thi-  matches  also,  as  does  the  space.  \V  e must 
now  apply  Rule  2 to  t no  node  reached  by  the  space  and 


the  input  character  A.  Notice  here  that  there  is  a branch 
leaving  the  node  which  matches  A.  Thus  Rule  2 is  applied 
again  to  the  node  reached  by  that  branch  and  the  terminat- 
ing element  of  the  input  line.  We  have  a match  here,  too, 
and  Rule  2 therefore  states  that  the  match  is  successful. 
Because  of  the  fact  that  a parameter  flag  must  match  a 
balanced  substring  of  the  input  line.  (B  = C)  =•  A is 
recognized  as  an  instance  of  template  4,  and  (B  = C)  will 
be  the  value  of  the  first  actual  parameter.  If  the  line  wi  n 
(B  = C)  = D - A,  the  reasoning  of  the  previous  paragraph 
shows  that  it  would  match  template  a. 

The  template-matching  scheme  described  in  this  \p 
pemlix  permits  flexibility  in  the  format  of  a macro  call. 
It  accommodates  varying  language  styles  but  dm  - require 
that  only  one  statement  be  written  per  line.  Spaces  arc 
significant.  The  fact  that  each  parameter  flag  matches  a 
balanced  substring  of  the  input  line  allows  for  gr  uip  ng 
of  text  by  parentheses. 
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